WO2023232888A1 - Infrastructure de sécurité; procédé et produit programme d'ordinateur associés - Google Patents
Infrastructure de sécurité; procédé et produit programme d'ordinateur associés Download PDFInfo
- Publication number
- WO2023232888A1 WO2023232888A1 PCT/EP2023/064581 EP2023064581W WO2023232888A1 WO 2023232888 A1 WO2023232888 A1 WO 2023232888A1 EP 2023064581 W EP2023064581 W EP 2023064581W WO 2023232888 A1 WO2023232888 A1 WO 2023232888A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- client
- agent
- server
- service
- darknet
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 74
- 238000004590 computer program Methods 0.000 title claims description 4
- 238000004891 communication Methods 0.000 claims description 8
- 238000012795 verification Methods 0.000 claims description 5
- 241000234282 Allium Species 0.000 description 46
- 235000002732 Allium cepa var. cepa Nutrition 0.000 description 46
- 230000008569 process Effects 0.000 description 45
- 230000008520 organization Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000004870 electrical engineering Methods 0.000 description 1
- 238000010921 in-depth analysis Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000032258 transport Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
- H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
Definitions
- TITLE Security infrastructure; process and associated computer program product.
- the present invention relates to the field of computer network security.
- the Internet has been largely based on the TCP/IP model since its inception. According to this model, the services made available to users on the internet are “exposed” to the whole world.
- a Web application - that is to say an application that can be manipulated directly online using a remote browser
- a VPN application - that is to say an application allowing the establishment of a communication tunnel secure
- an API application - that is to say an application providing basic functionality to a remote application, etc.
- IPv4 address (4 bytes) and a port (2 bytes).
- the Darknet network It is a peer-to-peer, distributed computer network superimposed (or “overlay” network in English) on the Internet network. He uses specific protocols integrating anonymity functions allowing the IP addresses of actors not to be publicly revealed.
- the Darknet network comprises a plurality of nodes, in particular nodes having a function of router of the Darknet network ("onion router” - OR, such as “introduction point” nodes – InP and “rendezvous point” nodes – RP) and nodes having a Darknet network directory function (“Hidden Service Directory” – HSDir).
- a client has the address on the Darknet network (or onion address) of the service it seeks to access and which is hidden on the Darknet network. How the client obtains this onion address is not part of the standard implementation of a Darknet network.
- the client negotiates a connection to access the hidden service.
- the client finds, from the onion address of the hidden service and a short-lived random variable provided by the Darknet network, and using an adapted hash function , the IP addresses of a set of HSDir directories.
- the client selects one of these IP addresses and establishes a connection with the corresponding HSDir. This is a “direct” connection using classic Internet communication methods.
- the HSDir directory then sends the client a document for further negotiation. This document notably includes the IP addresses of a set of InP nodes for the second phase of the negotiation.
- the client randomly selects a node in the Darknet network as a meeting point - RP and establishes a connection to this meeting point.
- the client transmits a connection request to one of the introduction nodes - InP selected in the document received from the HSDir directory. This request contains in particular the address of the meeting point. This request is relayed through the Darknet network to the server.
- the server can implement authentication processes for the requesting client (as for example described in the work by LOESING Karsten, "Privacy-enhancing technologies for private services", April 24, 2009).
- the server establishes a connection to the meeting point.
- the meeting point connects the client and the server.
- the aim of the present invention is to solve the problem of exposure of services, by proposing an alternative solution to known solutions, which is based on the removal of exposure points.
- the invention relates to a security infrastructure intended to be deployed in an architecture based on the Internet and comprising a client connected to the Internet on one side and a server of a connected information system.
- the information system providing a service
- the security infrastructure is a Darknet infrastructure comprising: a Darknet network overlaying the Internet to hide the service; a client agent executed by the client to access the service through the Darknet network, the client agent storing a client configuration file; a server agent executed on the information system server to allow access to the service through the Darknet network, the server agent storing a server configuration file; and, a controller, comprising a database storing configuration information, the controller being accessible through the Darknet network by the client agent, respectively by the server agent, to receive client configuration information, respectively server, allowing updating the client or server configuration file, the client configuration information comprising at least one address on the Darknet network allowing the client to access the service when the client actually has the right to access the service, and the server configuration information comprising at
- the infrastructure comprises one or more of the following characteristics, taken individually or in all technically possible combinations:
- an agent among the client agent and the server agent memorizes a token allowing a first connection, via the Darknet network, to the controller in order to receive authentication data in return, the agent then establishing a connection with the controller by using authentication data.
- the infrastructure includes an administration console for the controller and advantageously for the server agent, the administration console running an agent to access the controller and advantageously the server agent through the Darknet network.
- the infrastructure is based on a Tor implementation of the Darknet infrastructure.
- the invention also relates to a method of connection to a hidden service implemented in a security infrastructure conforming to the previous infrastructure, consisting of: filling in a client configuration file of the client agent and filling in a configuration file server of the server agent by connection to the controller, the client configuration file comprising at least one address on the Darknet network of the service, and the server configuration file comprising at least one identification information allowing the client to identify itself with from the server to be able to access the service; make the service available on the Darknet network through the server agent; establish by the client agent a connection with a so-called “meeting point” node of the Darknet network (43), using the information contained in the client configuration file; request access to the service from the Darknet network by the client agent by declaring the identifier of the “meeting point” node; verify by the server agent the identity of the client on which the client agent is running using the identification information contained in the server configuration file; and, in the event of positive verification, establish by the server agent
- the process comprises one or more of the following characteristics, taken individually or in all technically possible combinations:
- the method further consists of: establishing a connection with the controller by the server agent; communicate by the server agent to the controller the address on the Darknet network of the service, said address having been generated by the server agent; establish a connection with the controller by the client agent; communicate by the controller to the client agent the address on the Darknet network of the service to fill in the client configuration file.
- the method further consists of: establishing a connection with the controller by the server agent; communicate by the controller to the server agent the user rights on the service to fill the server configuration file.
- the method further consists of: receiving by the agent a connection token indicating an address on the Darknet network of the controller and a login ; establish by the agent a connection to the controller using the address on the Darknet network of the controller indicated in the token and identify itself by the agent to the controller using the identifier indicated in the token; provide authentication data in response by the controller to the agent; and the agent establishes a connection to the controller using the authentication data.
- the invention also relates to a computer program product comprising software instructions which, when executed by a client, a server and a controller of an infrastructure conforming to the preceding infrastructure, implement a method conforming to the previous process.
- Figure 1 is a schematic representation of a preferred embodiment of a security infrastructure according to the invention, deployed to secure a computer architecture using the Internet;
- Figure 2 is a block representation of a first method implemented by the security infrastructure of Figure 1;
- Figure 3 is a block representation of a second method implemented by the security infrastructure of Figure 1;
- Figure 4 is a block representation of a third method implemented by the security infrastructure of Figure 1;
- Figure 5 is a block representation of a fourth method implemented by the security infrastructure of Figure 1.
- “User” this is the person who interacts with a computer connected to the Internet, called a “client computer” or “client”, to access a service. Unless otherwise stated, hereinafter we will speak without distinction of customer or user.
- Client application this is software executed by a client and must access a service to function correctly or offer a particular functionality to the client or user. Unless otherwise stated, we will hereinafter speak indiscriminately of client or client application.
- Service this is a functionality made available by an organization’s information system. This service is accessible via a server connected (directly or indirectly via a gateway) to the internet network. For example, the service is software run by the server computer. Unless otherwise stated, we will hereinafter speak indiscriminately of service or server.
- Darknet infrastructure in addition to the Darknet network, the Darknet infrastructure includes the software (or agents) executed on machines to allow them to use the Darknet network by implementing the appropriate protocols.
- Tor implementation (or “Tor technology”, or even “Tor software”) (acronym for “The “.onion” Router” or “the “.onion” router” in French): it is a particular implementation of Darknet infrastructure.
- the Tor implementation is a global, decentralized overlay computing network. It consists of a number of servers, called Darknet network nodes, the list of which is public. This network makes it possible to anonymize the origin of TCP connections.
- the Tor implementation is made up of free software, which is kept up to date by the organization “The T or Project”, whose website (https://forum.torproject.net) offers various information and makes available to all software versions.
- the latest stable version of the Tor implementation is version 0.4.7.7 of April 27, 2022. It should be noted that the present invention is based on the basic functionalities of the Tor implementation, which can be found in a version to another.
- “.onion” address according to the Tor implementation, access to a hidden service requires the user to know its “.onion” address.
- the “.onion” address allows you to negotiate “a meeting point” with the Darknet infrastructure. This meeting point is a node in the Darknet network used as a connection intermediary between the user and the service. No one can negotiate a meeting point with the hidden service without knowing the “onion” address of this service.
- the “.onion” address is generated exclusively on the service side.
- the “onion” address of a service is certainly known to the client, but is not known to other machines in the Darknet infrastructure (by using “blind cryptography” mechanisms, a service manages to declare to the Darknet without having to reveal your “.onion” address. Since they are made up of 56 semi-alphanumeric characters, it is very difficult to crack an “onion” address with a force attack.
- “Anonymity” according to the current version of the Tor implementation, in order not to expose the IP address of a machine, the connection created between this machine and the meeting point is not direct, but goes through one or more Darknet relay nodes between the machine and the meeting point. Thus, the compromise of the meeting point does not make it possible to obtain the IP address of the machine, in particular on the service side.
- Tor technology provides end-to-end encryption between machine and meeting point. More precisely, the data passing through is encrypted as many times as the number of relay nodes crossed (so-called “onion” encryption), thus avoiding the Compromise of part of the access path to the meeting point does not call into question the confidentiality of the data in transit.
- “Principle of indirection” this involves indirectly establishing a connection between the client and the server, according to the current version of the Tor implementation, the client chooses the meeting point within the Darknet network, builds a connection to this meeting point, then communicates the meeting point identifier to the service via a specific mechanism of Tor technology which is not detailed here.
- the service verifies the identity of the client seeking to establish a connection. In Tor technology, this verification is carried out using certificates stored locally on the service side. If the customer has the right to establish a connection, then the service creates a connection to the meeting point chosen by the customer. The service thus becomes the last actor to establish the connection.
- the invention consists of securing an IT architecture based on the Internet by deploying a suitable Darknet infrastructure, so as to remove the points of exposure of the services so as to make them invisible.
- the security infrastructure according to the invention is based on the use of the principle of indirection: the sensitive actors of client-server communication only use outgoing flows. These flows converge on the Darknet network.
- a server becomes the last actor to decide whether or not to establish a connection with a client. This decision is made based on a number of criteria, including the client's access rights.
- the security infrastructure according to the invention is based on the “ZTNA” model.
- the “ZTNA” model (for “Zero-Trust Network Access”) is a security concept, particularly applicable to computer networks, based on the systematic verification of user rights, considering that it does not It is not possible to trust a user by default. In this way, the compromise of part of the architecture does not call into question the confidentiality of the information exchanged between a client application and a server, does not call into question the anonymity of the service, nor the integrity of this service. .
- the security infrastructure implements the Tor implementation of a Darknet infrastructure. However, other implementations of a Darknet infrastructure could also be used, notably the I2P implementation (“Invisible Internet Project”).
- the security infrastructure according to the invention is deployed in an architecture comprising the Internet 30, a client 10 connected to the Internet 30 on one side, and an information system 20 connected to the internet on the other hand.
- the information system 20 includes a private network 21 connected to the Internet via a gateway 22.
- the information system 20 makes a service 23, called an application service, available to a set of remote users.
- the service 23 is for example executed on a server computer 24.
- the service 23 is for example a web application.
- the client 10 is a computer (such as a personal computer, a mobile telephone, etc.) which runs an application 12 needing access to the service 23 so that the user 1 of the client 10 fully benefits from the functionality associated with the execution of the application 12.
- the application 12 is for example an internet browser.
- the security infrastructure (generally referenced by the number 40 in Figure 1) includes:
- client-side agent or client agent 41;
- controller 44 preferably,
- Security infrastructure 40 is a Darknet infrastructure, conforming to the Tor implementation unless otherwise noted.
- the Darknet network 43 is a network composed of a plurality of nodes superimposed on the Internet 30.
- nodes are referenced by the numbers 51 and 52, 61, 62 and 63, and 71 and 72.
- the Darknet 43 network is advantageously deployed on several “cloud” networks, managed by different providers.
- the nodes of the Darknet network 43 are represented as belonging to three different cloud networks, respectively 50, 60 and 70.
- the providers are advantageously entities different from the organization managing the information system 20 or from the service provider providing this security solution.
- the distribution of the Darknet 43 network over a plurality of cloud networks ensures sufficient resilience, as well as extensive geographic coverage (for example global).
- the management system 45 of the Darknet 43 network is schematically represented. This is only a representation, insofar as the management functions are in fact distributed within the Darknet 43 network itself. , between the nodes composing it.
- the management system 45 notably includes the HSDir directories in accordance with a standard implementation as well as other “classic” directories. It includes mechanisms for publishing information concerning hidden services (via HSDir directories), or more generally information on the state of the Darknet (via “classic” directories). This information is necessary to establish a connection to a hidden service.
- the Darknet 43 network is private and not public (as in the Tor implementation). This means that it is not possible to add a node to the Darknet 43 network without being authorized to do so. In addition to certain security problems that this can cause, adding malicious nodes can cause performance problems if the bandwidth of the added nodes is not controlled.
- a candidate node is added to the network by declaring itself to nodes of the Darknet network having a high hierarchical level, also called “authority” nodes.
- the candidate node communicates a router description document (or “Router Descriptor”) to the “authority” nodes.
- the “authority” nodes include the information contained in the router description document within a consensus document, during a vote which takes place at regular intervals.
- the consensus document is a public document produced regularly by the Darknet network and which gives the list of all the nodes that compose it, as well as the cryptographic information associated with each of these nodes.
- the consensus document is notably used by the processes of the Tor implementation to construct the paths (also called "circuit" in the Tor implementation) to the meeting points, as will be described below.
- an additional certificate is integrated within the valid router description documents.
- This certificate is signed by a trusted authority and each “authority” node holds the authority certificate allowing it to validate the router description document of a candidate node by verifying its signature.
- the Common Name of a node's certificate of authority candidate specifies the public IP address of the candidate node and thus allows the “authority” nodes to verify the legitimacy of the candidate node requesting its integration into the Darknet 43 network.
- the Darknet 43 network has the capacity to refuse candidate nodes that do not have a valid certificate signed by the trusted authority.
- the Darknet 43 network is an alteration of the Tor implementation as defined by the current version of the standard.
- the client agent 41 which is installed and executed on a computer, like the client 10 of the user 1, allows access to the services concealed or hidden by the security infrastructure 40.
- the client agent 41 stores a client configuration file T.
- the file T includes authentication data of the client 10, such as for example a private key, a public key and a certificate associated with the public key for connection to the controller 44.
- the T file also stores the “.onion” addresses of the hidden services for which user 1 of client 10 has access rights.
- the T file associates each “.onion” address on the one hand, with an IP address and/or a domain name on the other hand.
- the client agent 41 advantageously memorizes a J1 token to allow a first connection to the services of the controller 44, which are services hidden by the Darknet network of the security infrastructure 40.
- the client agent 41 is composed of two processes.
- the first 411 process is a Tor process. This is a local proxy (also called “.Onion Proxy” - OP) listening on the local loop.
- This first process 411 accepts connections from the SOCKS protocol.
- the first process 41 1 redirects the data packets coming from the client application 12 to the services hidden by the Darknet network 43.
- the SOCKS protocol is a standard protocol, used in the T or implementation to provide applications running on a machine , a standard way to access the Darknet.
- the agent instead of configuring applications to use Tor's local SOCKS proxy, the agent is responsible for negotiating a SOCKS connection with the local proxy each time a connection with a hidden service is necessary.
- This first 411 process is similar to the local proxy of the Tor implementation, but is advantageously modified to ensure the creation of direct circuits to a meeting point so as to remove the anonymity of the client. Removal of anonymity of users allows the administrator of hidden services to know the real IP addresses of users. Thus, the connection between the client agent 41 and the meeting point is direct and does not use any intermediate relay node of the Darknet network 43. The hidden services remain anonymous. Removing client anonymity also increases the performance of the Darknet network, by reducing the relay and encryption steps for client-side flows.
- the second process 412 is specific to this security infrastructure. It establishes and maintains a connection to the controller 44, relying on the first process 41 1.
- This second process 412 is capable of connecting to a configuration service of the controller 44 to retrieve all or part of the information from the configuration file T.
- the second process 412 modifies this request by substituting the “.onion” address associated with this domain name or IP address, and redirects the modified request to the Darknet network and the hidden service, via the first process 411.
- the second process 412 intercepts DNS requests from the application 12 when these include a domain name from the file T.
- the second process forges a DNS response containing a “false” IP address associated with this domain name (this “fake” IP address is either indicated in the T file or a default address assigned by the second process).
- the second process 412 detects a request to this “fake” IP address, it redirects the packet to the local Tor proxy with the corresponding “.onion” address.
- This functionality of the second process 412 is not essential to the invention, but it makes it possible to make the proposed solution easier to use for the user, who does not manipulate “.onion” addresses but IP addresses or domain names, as he is used to when using the Internet. But the 412 process itself is essential, in particular to communicate with the controller and receive information on the accessible services.
- the server agent 42 is installed and executed on a machine of the information system 20, in order to hide this or that service of the information system. For example, the server agent 42 is executed by the server 24 to hide the service 23. The server agent 42 then makes it possible to make the service accessible through the security infrastructure 40.
- the server agent 42 stores a server configuration file F.
- the file F includes authentication data from the server 24, such as for example a private key, a public key and a certificate associated with the public key, for connection to the controller 44.
- the F file also stores the identification information associated with the users who can access the service 23.
- This identification information preferably includes authentication data of each client and the access rights associated with this client.
- the server agent 42 memorizes a J2 token to allow a first connection to the controller 44.
- Server agent 42 is made up of two processes.
- the first 421 process is a Tor process. It makes it possible to generate the “.onion” addresses of the services to be hidden and to declare them to the management system 45 of the Darknet network 43 to make them accessible to authorized users via the Darknet.
- the first process 421 reads the configuration file F containing this information. Just as for the client agent 41, this first process 421 executes a local proxy to provide access to the Darknet network 43. This first process 421 conforms to the local proxy according to the Tor implementation.
- the second process 422 is specific to the present invention. It allows an administrator 28 of the information system 20 to communicate with the first process 421 in order to configure the services.
- the administrator 28 accesses the second process 422 as a service hidden by the Darknet.
- the second process 422 also makes it possible to establish and maintain a connection with the controller 44 to receive information allowing the configuration file F to be updated.
- Controller 44 is a machine connected to the internet.
- the controller 44 includes a database B. This contains the information allowing the client and server configuration files to be updated.
- Database B references, for example, users, services and access rights to these services by users.
- Each service offered by controller 44 is a service hidden by the Darknet network
- the controller 44 is advantageously hosted in an information system different from the information system to be secured and managed by the supplier of this security solution.
- controllers there are as many controllers as there are organizations whose information system we seek to secure so that the services of these different organizations are not referenced within the same controller. This partitioning between organizations helps increase security.
- the controller 44 executes a process 441 and two services of the network application type 442 and 443. These two applications act as services hidden by the Darknet network 43. They are themselves informed within the controller 44 and can be administered as any what other hidden service.
- the 441 process is a Tor process, of the local proxy type.
- the process 441 makes it possible to generate the two “.onion” addresses of the two services 442 and 443 to make these services accessible to remote agents, clients of the controller services, through the Darknet 43 network.
- the first application 442 which corresponds to a configuration service, listens to a first port on the local loop to allow agents to connect, authenticate and receive the information that interests them, such as for example, “.onion” addresses. services open to the user for the client agent 41, or the domain names and/or IP addresses for the client agent 41, or even the identities of authorized users for the server agent 42.
- the controller 44 can be administered through the second application 443, which corresponds to an administration service, which is a web application accessible via a second port, distinct from the first port.
- the administrator 28 of the security infrastructure knows the “.onion” address allowing him to access the second application 443 of the controller 44 and to manage the users, services and associated access rights, this is i.e. to update the contents of database B.
- the administrator 28 accesses the information service 20 and the controller 44 by means of a console 46.
- the console 46 is a client, similar to the client 10 presented above. It executes an application 12' for administration of the information system 20 and the controller 44 which can connect through the Darknet network 43 by executing a client agent 4 T (comprising a first process 411' and a second process 412') using the information grouped in a configuration file T'.
- a connection method 100 is implemented to establish a connection (for example the connection 101 of Figure 1) between an application of a registered client, such as the application 12 of client 10, and a hidden service, such as service 23 of server 24.
- Step 110 when a user 1 seeks to use a hidden service 23, the client agent 41 reads the client configuration file T to extract the “.onion” address of the service to which it wishes to access. It establishes a connection with a Darknet meeting point, for example node 61. To do this, the client agent 41 arbitrarily chooses this node from the list of nodes which make up the Darknet network 43, this list being publicly available for example by querying the management system 45. The client agent 41 then establishes a connection with the chosen meeting node. In the present implementation, this connection is advantageously direct. That is to say that there is no relay node of the Darknet 43 network between client 10 and the chosen meeting point, to make it possible to break the anonymity of client 10.
- Step 120 once the connection to the Darknet network has been established, the client agent 41 requests access to the service 24 and declares its meeting point to the management system 45, which is responsible for communicating to the associated server agent 42 to the requested service, the connection request from the customer agent 41 and the location of the chosen meeting point.
- the management system 45 which is responsible for communicating to the associated server agent 42 to the requested service, the connection request from the customer agent 41 and the location of the chosen meeting point.
- Step 130 upon receiving a connection request to the service 23, the server agent 42 verifies the identity of the client 10 by consulting the server configuration file F.
- Step 140 after positive verification of the identity of the client having initiated a connection request, the server agent 42 initiates a TCP connection to a first node of the Darknet network, for example node 52. Then the server agent 42 extends the previously established connection by indicating to the first relay node 52 of the circuit to establish a TCP connection to a second relay node, chosen by the first relay node, for example node 71. Finally, the server agent 42 extends the connection a again, until meeting point 61. Alternatively, the circuit between the information system 20 and the point of rendezvous can have another number of hops (at least two to hide the server IP 24).
- Step 150 the connections on either side of the meeting point are associated by the meeting point to allow the client agent 41 and the server agent 42 to establish a secure tunnel, and to allow the application 12 executed on the client 10 and the service 23 executed by the server 24 to communicate.
- Client 10 does not know the effective IP address of service 23, while service 23 knows that of the client which is transmitted to it by the meeting point.
- the steps of the method 200 are advantageously implemented to populate the client T and server F configuration files.
- a step 210 the administrator 28 connects, via the Darknet, to the controller 44 to access the identity and access administration service. It adds to the database B a right to the client 10 of the user 1 to allow access to the hidden service 23.
- the console 46 as a client and the controller 44 as a server of a hidden service carries out the steps of the connection method 100 to establish the connection 401.
- the second application 443 allows the administrator to have control over database B.
- a step 220 the controller 44 communicates the identity of the user and his rights to the server agent 42.
- This step is for example executed at the request of the server agent 42 when it must verify a connection request (step 130 of process 100).
- the server agent 42 knows that it can authorize the establishment of a connection to the meeting point to respond to a connection request from the client 10.
- the communication of this information is carried out by means of a connection 301 through the Darknet previously established and maintained between the server agent 42, as client, and the first application 442, of the controller 44 (circuit 301 in Figure 1), as a hidden service.
- the controller 44 communicates the “.onion” address of the service 23 to the client agent 41. This communication is carried out via a secure tunnel previously established and maintained between the client agent 10 of the user 1, as a customer, and the first application 442 of the controller, as a hidden service (circuit 201 of Figure 1).
- the client 10 can then establish a secure tunnel to this service and the server agent 42 can verify the identity of the client and establish the connection to the meeting point in accordance with method 100.
- the implementation of the steps of the method 300 is advantageously provided to allow the authentication of a client 10 by the server agent 42 associated with the service 23 (step 130 of the method 100).
- the server agent 42 makes the application service 23 available on the Darknet 43, by generating a “.onion” address for the service 23, and registers the service 23 with the system 45 of the Darknet network 43.
- This functionality is native to the Tor implementation according to the current version and is not modified here.
- the server agent 42 establishes and maintains a connection 301, through the Darknet network 43, with the first application 442 of the access and identity controller 44.
- step 330 the server agent 42 also communicates to the controller 44 the “.onion” address that it generated for the service 23.
- step 340 the controller 44 communicates to the server agent 42 all the identities of the users having the right to establish a connection with the service 23 (this corresponds to step 220 of the method of Figure 3) .
- the controller 44 notifies the server agent 42.
- a step 350 upon receiving a connection request from the client agent 41, the server agent 42 verifies that the client 10 actually has the right to connect. If yes, it establishes a connection to the meeting point chosen by the client agent 41, following the principle of indirection (step 140 of the process of Figure 1).
- step 330 makes it possible to centralize the “.onion” addresses of the services of a given organization within the database B stored by the controller 44.
- the controller 44 thus references the users of the organization , services and access rights. This allows the controller 44, by means of the configuration service, to indicate to clients the “.onion” addresses of the accessible services, as described with reference to Figure 5.
- “.onion” addresses are considered information outside the scope of the standard, which it is the responsibility of service administrators to communicate to their users.
- the client 41 and server 43 agents need to know the “.onion” address of the first application 442 of the controller 44, they must have certain initial configuration information, such as a certificate, a key and the “.onion” address. .onion” of controller 44.
- the agent can advantageously retrieve this information directly from the controller 44 by implementing the steps of the method 400 of Figure 5.
- the user receives an initialization token.
- This is for example composed of the “.onion” address of controller 44 and a unique identifier.
- This pair of information is for example generated by the controller 44 at the request of the administrator 28.
- This pair of information is communicated to the user 1 (or to the administrator of the service to be hidden) by an additional means of communication with the appropriate level of security, for example by transmitting an encrypted email containing the token.
- the client agent 41 (respectively the server agent 42) connects to the controller 44. It reads the “.onion” address of the configuration service of the controller 44, indicated by the token, connects, via the Darknet network, to the configuration service of the controller 44, and transmits to the controller 44 the unique identifier indicated by the token.
- configuration service of the controller 44 In return, in a step 430, configuration service of the controller 44 generates a certificate and a key and transmits this authentication data to the client agent (or the server agent). The token is then “consumed” (invalidated) by the controller 44. A token is only valid for a limited time and can only be used once to guarantee security.
- the client agent 41 (respectively the server agent 42) has the possibility of establishing a new connection with the configuration service of the controller 44 and to authenticate with the controller 44 using the information from the file T (respectively from the file F).
- an agent maintains this connection with the controller.
- the client agent 41 retrieves, from the configuration service of the controller 44, general configuration information such as the “.onion” addresses of the hidden services which are open to it. It stores this information in the file T.
- the server agent 42 retrieves, from the configuration service of the controller 44, the general configuration information such as the identification of each user. It stores this information in the F file.
- a step 460 the client 10 accesses the desired hidden application service using its “.onion” address, by negotiating a meeting point with the Darknet network, then by establishing a connection with the hidden service via the process usual for the Tor implementation (implementation of method 100).
- the client and server agents know the “.onion” address of the controller 44.
- the controller 44 indicates this modification to the clients concerned: a new “.onion” address is available, a “.onion” address must be invalidated, a user has the right to access all or part of a hidden service or, on the contrary, no longer has the right to access all or part of a hidden service.
- the invention therefore relates to an infrastructure based on a private Darknet network making it possible to remove the exposure of services on the internet.
- the Darknet infrastructure is completed by the addition of a controller offering various hidden services to increase security: secure distribution of onion addresses to clients (preferably only to authorized clients); distribution of client identification information to servers, to strengthen the authentication of clients requiring access to a service provided by a server.
- the Tor implementation of a Darknet infrastructure is advantageously modified to remove the anonymity of users, while keeping that of hidden services.
- Customer agents advantageously allow users to access hidden services as if they were accessing services exposed on the internet.
- the proposed infrastructure has the following properties:
- the administration console is no longer exposed on the Internet and uses the infrastructure itself to hide itself.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
Infrastructure de sécurité; procédé et produit programme d'ordinateur associés. Cette infrastructure pour sécuriser la connexion via l'internet entre un client (10) et un serveur (24), le serveur mettant à disposition un service (23), est une infrastructure Darknet comportant : un réseau Darknet (43); un agent client (41) exécuté par le client (10) et mémorisant un fichier de configuration client (T); un agent serveur (42) exécuté sur le serveur (24) et mémorisant un fichier de configuration serveur (F); et un contrôleur (44), comportant une base de données (B) stockant des informations de configuration, le contrôleur étant accessible à travers le réseau Darknet (43) par l'agent client (41), respectivement par l'agent serveur (42), pour recevoir des informations de configuration client, respectivement serveur, permettant la mise à jour du fichier de configuration client, respectivement serveur.
Description
DESCRIPTION
TITRE : Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.
La présente invention concerne le domaine de la sécurité informatique des réseaux.
Internet est largement basé sur le modèle TCP/IP depuis sa création. Selon ce modèle, les services mis à disposition des utilisateurs sur internet sont « exposés » au monde entier. Comme exemples de service, on peut citer une application Web - c’est-dire une application manipulable directement en ligne grâce à un navigateur distant, une application VPN - c’est-à-dire une application permettant d’établir un tunnel de communication sécurisé, une application API - c’est-à-dire une application fournissant une fonctionnalité élémentaire à une application distante, etc.
Lorsqu’un service est exposé, il n’a d’autre choix que de « subir » les sollicitations de connexions de la part des clients.
Un service exposé sur internet est identifiable, le plus souvent, par une adresse IPv4 (4 octets) et un port (2 octets).
Il est ainsi possible de scanner l’internet pour disposer d’une cartographie de tous les services exposés.
Cela signifie que les services exposés sont trouvables par des attaquants. Les attaquants listent des services exposés d’une organisation donnée, recherche les vulnérabilités de ces services, puis lancent une attaque ciblée sur le service pour compromettre le système d’information. On constate que plus d’un tiers des compromissions de systèmes d’information sont dues à l’exploitation de vulnérabilités qui affectent un service exposé sur internet du système informatique compromis.
Différentes manières de traiter ce problème ont été proposées, comme : la mise en place de pare-feu qui filtrent les tentatives de connexion ; l’analyse en profondeur du trafic et de blocage des tentatives de compromission ; le déploiement de processus de mise à jour des services exposés (avec la correction des vulnérabilités identifiées) ; la réduction de la surface d’exposition du système d’information (en déplaçant un service exposé sur internet vers l’intérieur du système d’information, puis en le rendant accessible à travers un seul point d’exposition, le plus souvent au moyen d’un VPN) ; le transfert des services exposés vers le cloud d’un tiers, qui en prend la responsabilité et en assure la protection.
Par ailleurs, on connaît le réseau Darknet. Il s’agit d’un réseau informatique pair à pair, distribué, superposé (ou réseau « overlay » en anglais) au réseau internet. Il utilise
des protocoles spécifiques intégrant des fonctions d'anonymat permettant que les adresses IP des acteurs ne soient pas dévoilées publiquement.
Dans son implémentation standard, par exemple présentée dans l’article de PENGPENG Wang et al., "Simulation of Dark Network Scene Based on the Big Data Environment", INFORMATION TECHNOLOGY AND ELECTRICAL ENGINEERING 2018, ACM, 2 PENN PLAZA, SUITE 701 NEW YORKNY10121 -0701 USA, 7 décembre 2018 (2018-12-07), pages 1 -6, le réseau Darknet comporte une pluralité de nœuds, notamment des nœuds ayant une fonction de routeur du réseau Darknet (« onion routeur » - OR, comme des nœuds « introduction point » - InP et des nœuds « rendez-vous point » - RP) et des nœuds ayant une fonction d'annuaire du réseau Darknet (« Hidden Service Directory » - HSDir).
Un client possède l'adresse sur le réseau Darknet (ou adresse oignon) du service qu'il cherche à accéder et qui est caché sur le réseau Darknet. La manière dont le client se procure cette adresse oignon ne fait pas partie de l'implémentation standard d'un réseau Darknet.
Sur la base de cette adresse oignon que le client négocie une connexion pour accéder au service caché. En particulier, dans une première phase de cette négociation, le client retrouve, à partir de l'adresse oignon du service caché et d'une variable aléatoire à durée de vie courte fournie par le réseau Darknet, et en utilisant une fonction de hachage adaptée, les adresses IP d'un ensemble d'annuaires HSDir.
Le client sélectionne une de ces adresses IP et établit une connexion avec le HSDir correspondant. Il s'agit d'une connexion « directe » selon des méthodes de communication classiques de l’Internet. L'annuaire HSDir transmet alors au client un document pour la suite de la négociation. Ce document comporte notamment les adresses IP d’un ensemble de nœuds InP pour la seconde phase de la négociation.
Dans cette seconde phase, le client sélectionne, de manière aléatoire, un nœud du réseau Darknet en tant que point de rendez-vous - RP et établit une connexion jusqu’à ce point de rendez-vous. Parallèlement, le client transmet une requête de connexion à l'un des nœuds d’introduction - InP sélectionné dans le document reçu de l’annuaire HSDir. Cette requête contient en particulier l'adresse du point de rendez-vous. Cette requête est relayée à travers le réseau Darknet vers le serveur.
Lors de la réception de cette requête, le serveur peut mettre en œuvre des processus d'authentification du client requérant (comme par exemple décrits dans l’ouvrage de LOESING Karsten, "Privacy-enhancing technologies for private services", 24 avril 2009). En cas d'authentification réussie, le serveur établit une connexion jusqu'au point de rendez-vous.
Finalement, le point de rendez-vous connecte le client et le serveur.
Le but de la présente invention est de résoudre le problème de l’exposition des services, en proposant une solution alternative aux solutions connues, qui est fondée sur la suppression des points d’exposition.
Pour cela l’invention a pour objet une infrastructure de sécurité destinée à être déployée dans une architecture s’appuyant sur l’internet et comportant un client connecté à l’internet d’un côté et un serveur d’un système d’information connecté à l’internet d’un autre côté, le système d’information mettant à disposition un service, caractérisée en ce que l’infrastructure de sécurité est une infrastructure Darknet comportant : un réseau Darknet en superposition de l’internet pour cacher le service ; un agent client exécuté par le client pour accéder au service à travers le réseau Darknet, l’agent client mémorisant un fichier de configuration client ; un agent serveur exécuté sur le serveur du système d’information pour permettre un accès au service à travers le réseau Darknet, l’agent serveur mémorisant un fichier de configuration serveur ; et, un contrôleur, comportant une base de données stockant des informations de configuration, le contrôleur étant accessible à travers le réseau Darknet par l’agent client, respectivement par l’agent serveur, pour recevoir des informations de configuration client, respectivement serveur, permettant la mise à jour du fichier de configuration client, respectivement serveur, les informations de configuration client comportant au moins un adresse sur le réseau Darknet permettant au client d’accéder au service lorsque le client a effectivement le droit d’accéder au service, et les informations de configuration serveur comportant au moins des informations d’identification permettant au client de s’identifier auprès du serveur pour pouvoir accéder au service.
Suivant des modes particuliers de réalisation, l’infrastructure comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles :
- un agent parmi l’agent client et l’agent serveur mémorise un jeton permettant une première connexion, via le réseau Darknet, au contrôleur afin de recevoir en retour des données d’authentification, l’agent établissant ensuite une connexion avec le contrôleur en utilisant les données d’authentification.
- l’infrastructure comporte une console d’administration du contrôleur et avantageusement de l’agent serveur, la console d’administration exécutant un agent pour accéder au contrôleur et avantageusement à l’agent serveur à travers le réseau Darknet.
- l’infrastructure est fondée sur une implémentation Tor de l’infrastructure Darknet.
- le réseau Darknet est un réseau privé.
L’invention a également pour objet un procédé de connexion à un service caché mis en œuvre dans une infrastructure de sécurité conforme à l’infrastructure précédentes, consistant à : renseigner un fichier de configuration client de l’agent client et renseigner un fichier de configuration serveur de l’agent serveur par connexion au contrôleur, le fichier de configuration client comportant au moins une adresse sur le réseau Darknet du service, et le fichier de configuration serveur comportant au moins une information d’identification permettant au client de s’identifier auprès du serveur pour pouvoir accéder au service ; rendre par l’agent serveur le service disponible sur le réseau Darknet ; établir par l’agent client une connexion avec un nœud dit « point de rendez-vous » du réseau Darknet (43), en utilisant les informations contenues dans le fichier de configuration client ; demander par l’agent client un accès au service auprès du réseau Darknet en déclarant l’identifiant du nœud « point de rendez-vous » ; vérifier par l’agent serveur d’identité du client sur lequel est exécuté l’agent client en utilisant les informations d’identification contenues dans le fichier de configuration serveur ; et, en cas de vérification positive, établir par l’agent serveur une connexion avec le nœud « point de rendez-vous » du réseau Darknet ; associer les connexions de part et d’autre du nœud « point de rendez-vous » pour établir une communication entre le client et le serveur.
Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles :
- le procédé consiste en outre à : établir par l’agent serveur une connexion avec le contrôleur ; communiquer par l’agent serveur au contrôleur l’adresse sur le réseau Darknet du service, ladite adresse ayant été générée par l’agent serveur ; établir par l’agent client une connexion avec le contrôleur; communiquer par le contrôleur à l’agent client l’adresse sur le réseau Darknet du service pour renseigner le fichier de configuration client.
- le procédé consiste en outre à : établir par l’agent serveur une connexion avec le contrôleur ; communiquer par le contrôleur à l’agent serveur les droits des utilisateurs sur le service pour renseigner le fichier de configuration serveur.
- pour établir par un agent parmi l’agent client et l’agent serveur une connexion avec le contrôleur, le procédé consiste, en outre, à : recevoir par l’agent un jeton de connexion indiquant une adresse sur le réseau Darknet du contrôleur et un identifiant ; établir par l’agent une connexion au contrôleur en utilisant l’adresse sur le réseau Darknet du contrôleur indiquée dans le jeton et s’identifier par l’agent auprès du contrôleur en utilisant l’identifiant indiqué dans le jeton ; fournir en réponse par le contrôleur à l’agent des données d’authentification ; et établir par l’agent une connexion au contrôleur en utilisant les données d’authentification.
L’invention a également pour objet un produit programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un client, un serveur et un contrôleur d’une infrastructure conforme à l’infrastructure précédente, mettent en œuvre un procédé conforme au procédé précédent.
L’invention et ses avantages seront mieux compris à la lecture de la description détaillée qui va suivre d’un mode de réalisation particulier, donné uniquement à titre d’exemple non limitatif, cette description étant faite en se référant aux dessins annexés sur lesquels :
La figure 1 est une représentation schématique d’un mode de réalisation préféré d’une infrastructure de sécurité selon l’invention, déployée pour sécuriser une architecture informatique utilisant l’internet ;
La figure 2 est une représentation sous forme de blocs d’un premier procédé mis en œuvre par l’infrastructure de sécurité de la figure 1 ;
La figure 3 est une représentation sous forme de blocs d’un second procédé mis en œuvre par l’infrastructure de sécurité de la figure 1 ;
La figure 4 est une représentation sous forme de blocs d’un troisième procédé mis en œuvre par l’infrastructure de sécurité de la figure 1 ; et,
La figure 5 est une représentation sous forme de blocs d’un quatrième procédé mis en œuvre par l’infrastructure de sécurité de la figure 1.
DEFINITIONS
« Utilisateur » : c’est la personne qui interagit avec un ordinateur connecté au réseau internet, dénommé « ordinateur client » ou « client », pour accéder à un service. Sauf mention contraire, on parlera ci-après indistinctement de client ou d’utilisateur.
« Application client » : c’est un logiciel exécuté par un client et devant accéder à un service pour fonctionner correctement ou offrir une fonctionnalité particulière au client ou à l’utilisateur. Sauf mention contraire, on parlera ci-après indistinctement de client ou d’application client.
« Service » : c’est une fonctionnalité mise à disposition par le système d’information d’une organisation. Ce service est accessible via un serveur connecté (directement ou indirectement par l’intermédiaire d’une passerelle) au réseau internet. Par exemple, le service est un logiciel exécuté par l’ordinateur serveur. Sauf mention contraire, on parlera ci-après indistinctement de service ou de serveur.
« Réseau Darknet » ou « Darknet » : c’est un réseau informatique pair à pair, distribué, superposé (ou réseau « overlay » en anglais) au réseau internet. Il utilise des
protocoles spécifiques intégrant des fonctions d'anonymat permettant que les adresses IP des acteurs ne soient pas dévoilées publiquement.
« Infrastructure Darknet » : en plus du réseau Darknet, l’infrastructure Darknet englobe les logiciels (ou agents) exécutés sur les machines pour permettre à celles-ci d’utiliser le réseau Darknet en mettant en œuvre les protocoles adaptés.
« Implémentation Tor » (ou « technologie Tor », ou encore « logiciel Tor ») (acronyme de « The “.onion » Router » ou « le routeur “.onion » » en français) : c’est une implémentation particulière d’une infrastructure Darknet. L’implémentation Tor est un réseau informatique superposé mondial et décentralisé. Il se compose d'un certain nombre de serveurs, appelés nœuds du réseau Darknet et dont la liste est publique. Ce réseau permet d'anonymiser l'origine de connexions TCP. L’implémentation Tor est composée de logiciels libres, qui sont tenus à jour par l’organisation « The T or Projet », dont le site internet (https://forum.torproject.net) offre différentes informations et met à la disposition de tous les versions des logiciels. Le dernière version stable de l’implémentation Tor est la version 0.4.7.7 du 27 avril 2022. Il est à noter que la présente invention s’appuie sur les fonctionnalités de base de l’implémentation Tor, que l’on retrouve d’une version à l’autre.
Adresse «.onion » : selon l’implémentation Tor, l’accès à un service caché nécessite que l’utilisateur connaisse l’adresse « .onion » de celui-ci. L’adresse « .onion » permet de négocier « un point de rendez-vous » avec l’infrastructure Darknet. Ce point de rendez- vous est un nœud du réseau Darknet utilisé comme intermédiaire de connexion entre l’utilisateur et le service. Personne ne peut négocier de point de rendez-vous avec le service caché sans connaître l’adresse « onion » de ce service. L’adresse « .onion » est générée exclusivement côté service. De plus, l’adresse « onion » d’un service est certes connue du client, mais n’est pas connue des autres machines de l’infrastructure Darknet (en utilisant des mécanismes de « cryptographie en aveugle », un service parvient à se déclarer auprès du Darknet sans avoir à révéler son adresse « .onion ». Dans la mesure où elles sont composées de 56 caractères semi-alphanumériques, il est très difficile de craquer une adresse « onion » par une attaque en force.
« Anonymat » : selon la version en vigueur de l’implémentation Tor, pour ne pas exposer l’adresse IP d’une machine, la connexion créée entre cette machine et le point de rendez-vous n’est pas directe, mais passe par un ou plusieurs nœuds relais du Darknet entre la machine et le point de rendez-vous. Ainsi, la compromission du point de rendez- vous ne permet pas d’obtenir l’adresse IP de la machine, en particulier côté service. De plus, la technologie Tor assure un chiffrement de bout en bout entre machine et point de rendez-vous. Plus précisément, les données qui transitent sont chiffrées autant de fois que le nombre de nœuds relais traversés (chiffrement dit « en oignon»), évitant ainsi que la
compromission d’une partie du chemin d’accès au point de rendez-vous ne remette en cause la confidentialité des données qui transitent.
« Principe d’indirection » : il s’agit d’établir indirectement une connexion entre le client et le serveur, selon la version en vigueur de l’implémentation Tor, le client choisit le point de rendez-vous au sein du réseau Darknet, construit une connexion jusqu’à ce point de rendez-vous, puis communique l’identifiant du point de rendez-vous au service via un mécanisme spécifique de la technologie Tor qui n’est pas détaillé ici. Le service vérifie l’identité du client qui cherche à établir une connexion. Dans la technologie Tor, cette vérification est effectuée au moyen de certificats stockés localement côté service. Si le client a le droit d’établir une connexion, alors le service crée une connexion jusqu’au point de rendez-vous choisi par le client. Le service devient ainsi le dernier acteur à établir la connexion. Il passe d’un composant passif (dans TCP/IP, le service accepte une connexion émanant d’un client) à un composant actif (dans une infrastructure Darknet, le service établit la connexion vers le point de rendez-vous). De plus, les points de rendez-vous ne sont jamais les mêmes car choisis aléatoirement par les clients au sein des nœuds du réseau Darknet.
GENERALITES
L’invention consiste à sécuriser une architecture informatique s’appuyant sur internet en déployant une infrastructure Darknet adaptée, de manière à supprimer les points d’exposition des services de manière à les rendre invisibles.
L’infrastructure de sécurité selon l’invention est fondée sur l’emploie du principe d’indirection : les acteurs sensibles de la communication client - serveur n’emploient que des flux sortants. Ces flux convergent vers le réseau Darknet. En particulier, un serveur devient le dernier acteur à décider d’établir ou non une connexion avec un client. Cette décision est prise en fonction d’un certain nombre de critères, notamment les droits d’accès du client.
L’infrastructure de sécurité selon l’invention s’appuie sur le modèle « ZTNA ». Le modèle « ZTNA » (pour « Zero-Trust Network Access » ou « accès réseau zéro confiance ») est un concept de sécurité, notamment applicable aux réseaux informatiques, fondé sur la vérification systématique des droits des utilisateurs, considérant qu’il n’est pas possible de faire confiance à un utilisateur par défaut. De la sorte, la compromission d’une partie de l’architecture ne remet pas en cause la confidentialité des informations échangées entre une application client et un serveur, ne remet pas en cause l’anonymat du service, ni l’intégrité de ce service.
Dans le mode de réalisation préféré décrit ci-dessous en détails, l’infrastructure de sécurité met en œuvre l’implémentation Tor d’une infrastructure Darknet. Cependant, d’autres implémentations d’une infrastructure Darknet pourraient tout aussi bien être utilisées, notamment l’implémentation I2P (« Invisible Internet Project » ou « projet d’internet invisible »).
ARCHITECTURE
En se référant à la figure 1 , l’infrastructure de sécurité selon l’invention est déployée dans une architecture comportant l’internet 30, un client 10 connecté à l’internet 30 d’un côté, et un système d’information 20 connecté à l’internet d’un autre côté.
Le système d’information 20 comporte un réseau privé 21 connecté à l’internet via une passerelle 22. Le système d’information 20 met à disposition un service 23, dit service applicatif, à un ensemble d’utilisateurs distants. Le service 23 est par exemple exécuté sur un ordinateur serveur 24. Le service 23 est par exemple une application web.
Le client 10 est un ordinateur (comme un ordinateur personnel, un téléphone mobile, etc.) qui exécute une application 12 ayant besoin d’accéder au service 23 pour que l’utilisateur 1 du client 10 bénéficie pleinement de la fonctionnalité associée à l’exécution de l’application 12. L’application 12 est par exemple un navigateur internet.
L’infrastructure de sécurité (référencée de manière générale par le chiffre 40 sur la figure 1 ) comporte :
- un réseau Darknet 43 ;
- un agent côté client (ou agent client) 41 ;
- un agent côté service (ou agent serveur) 42;
- un contrôleur 44 ; et, de préférence,
- une console d’administration 46.
L’infrastructure de sécurité 40 est une infrastructure Darknet, conforme à l’implémentation Tor sauf mention contraire.
Réseau Darknet 43
Le réseau Darknet 43 est un réseau composé d’une pluralité de nœuds en superposition de l’internet 30. Sur la figure 1 , on a référencé des nœuds par les chiffres 51 et 52, 61 , 62 et 63, et 71 et 72.
Le réseau Darknet 43 est avantageusement déployé sur plusieurs réseaux « en nuage » (« cloud » en anglais), gérés par des fournisseurs différents. Ainsi, sur la figure 1 , on a représenté les nœuds du réseau Darknet 43 comme appartenant à trois réseaux en nuage différents, respectivement 50, 60 et 70. Les fournisseurs sont avantageusement des
entités différentes de l’organisation gérant le système d’information 20 ou du prestataire fournissant la présente solution de sécurisation. La distribution du réseau Darknet 43 sur une pluralité de réseaux en nuage permet d’assurer une résilience suffisante, ainsi qu’une couverture géographique étendue (par exemple mondiale).
Sur la figure 1 , est représenté de manière schématique le système de gestion 45 du réseau Darknet 43. Ceci n’est qu’une représentation, dans la mesure où les fonctions de gestion sont en fait réparties au sein du réseau Darknet 43 lui-même, entre les nœuds le composant. Le système de gestion 45 inclut notamment les annuaires HSDir conformément à une implémentation standard ainsi que d’autre annuaires « classiques ». Il inclut les mécanismes permettant de publier les informations concernant les services cachés (via les annuaires HSDir), ou de manière plus générale les informations sur l’état du Darknet (via des annuaires « classiques »). Ces informations sont nécessaires à l’établissement d’une connexion vers un service caché.
Avantageusement, dans la présente implémentation, le réseau Darknet 43 est privé et non pas public (comme dans l’implémentation Tor). Cela signifie qu’il n’est pas possible d’ajouter un nœud au réseau Darknet 43 sans y être autorisé. Outre certains problèmes de sécurité que cela peut engendrer, l’ajout de nœuds malveillants peut poser des problèmes de performances si la bande passante des nœuds ajoutés n’est pas maîtrisée.
Selon l’implémentation Tor, un nœud candidat se rajoute au réseau en se déclarant auprès de nœuds du réseau Darknet ayant un niveau hiérarchique élevé, aussi dénommés nœuds « autorités ». Pour ce faire, le nœud candidat communique un document de description de routeur (ou « Router Descriptor ») aux nœuds « autorités ». Les nœuds « autorités » incluent les informations contenues dans le document de description de routeur au sein d’un document de consensus, lors d’un vote qui a lieu à intervalle régulier. Le document de consensus est un document public produit régulièrement par le réseau Darknet et qui donne la liste de tous les nœuds qui le composent, ainsi que les informations cryptographiques associées à chacun de ces nœuds. Le document de consensus est notamment utilisé par les processus de l’implémentation Tor pour construire les chemins (aussi dénommé « circuit » dans l’implémentation Tor) jusqu’aux points de rendez-vous, comme cela sera décrit ci-dessous.
Selon l’invention, afin d’éviter que le document de description de routeur d’un nœud non autorisé soit accepté par les nœuds « autorités », un certificat supplémentaire est intégré au sein des documents de description de routeur valides. Ce certificat est signé par une autorité de confiance et chaque nœud « autorité » détient le certificat d’autorité lui permettant de valider le document de description de routeur d’un nœud candidat en vérifiant sa signature. Le nom commun (« Common Name ») du certificat d’autorité d’un nœud
candidat spécifie l’adresse IP publique du nœud candidat et permet ainsi aux nœuds « autorités » de vérifier la légitimité du nœud candidat demandant son intégration au réseau Darknet 43. Ainsi, le réseau Darknet 43 a la capacité de refuser les nœuds candidats ne disposant pas d’un certificat valide et signé par l’autorité de confiance.
En cela, le réseau Darknet 43 est une altération de l’implémentation Tor telle que définie par la version actuelle du standard.
Agent client 41
L’agent client 41 , qui s’installe et s’exécute sur un ordinateur, comme le client 10 de l’utilisateur 1 , permet d’accéder aux services dissimulés ou cachés par l’infrastructure de sécurité 40.
L’agent client 41 mémorise un fichier de configuration client T.
Le fichier T comporte des données d’authentification du client 10, comme par exemple une clé privée, une clé publique et un certificat associé à la clé publique pour la connexion au contrôleur 44.
Le fichier T mémorise également les adresses « .onion » des services cachés pour lesquels l’utilisateur 1 du client 10 a des droits d’accès.
Avantageusement, le fichier T associe chaque adresse « .onion » d’une part, à une adresse IP et/ou un nom de domaine d’autre part.
L’agent client 41 mémorise avantageusement un jeton J1 pour permettre une première connexion aux services du contrôleur 44, qui sont des services cachés par le réseau Darknet de l’infrastructure de sécurité 40.
L’agent client 41 est composé de deux processus.
Le premier processus 411 est un processus Tor. Il s’agit d’un mandataire local (aussi appelé «.Onion Proxy » - OP) en écoute sur la boucle locale. Ce premier processus 411 accepte les connexions depuis le protocole SOCKS. Le premier processus 41 1 redirige les paquets de données provenant de l’application client 12 vers les services cachés par le réseau Darknet 43. Le protocole SOCKS est un protocole standard, employé dans l’implémentation T or pour fournir aux applications exécutées sur une machine, une manière standard d’accéder au Darknet. Dans la présente implémentation, au lieu de configurer les applications pour qu’elles utilisent le mandataire SOCKS local de Tor, c’est l’agent qui se charge de négocier une connexion SOCKS avec le mandataire local à chaque fois qu’une connexion avec un service caché est nécessaire.
Ce premier processus 411 est similaire au mandataire local de l’implémentation Tor, mais est avantageusement modifié pour assurer la création de circuits directs vers un point de rendez-vous de façon à supprimer l’anonymat du client. La suppression de l’anonymat
des utilisateurs permet à l’administrateur des services cachés de connaître les véritables adresses IP des utilisateurs. Ainsi, la connexion entre l’agent client 41 et le point de rendez- vous est directe et n’emploie aucun nœud relai intermédiaire du réseau Darknet 43. Les services cachés restent quant à eux anonymes. La levée de l’anonymat du client permet également d’augmenter la performance du réseau Darknet, en réduisant les étapes de relai et de chiffrement des flux côté client.
Le second processus 412 est spécifique à la présente infrastructure de sécurité. Il établit et maintient une connexion vers le contrôleur 44, en s’appuyant sur le premier processus 41 1 .
Ce second processus 412 est propre à se connecter à un service de configuration du contrôleur 44 pour récupérer tout ou partie des informations du fichier de configuration T.
Lorsqu’il détecte une requête générée par l’application 12, exécutée sur le client 10, à destination d’un nom de domaine ou d’une adresse IP mentionné dans le fichier T, le second processus 412 modifie cette requête en substituant l’adresse « .onion» associée à ce nom de domaine ou à cette adresse IP, et redirige la requête modifiée vers le réseau Darknet et le service caché, via le premier processus 411 .
Plus précisément, le second processus 412 intercepte les requêtes DNS de l’application 12 lorsque celles-ci comportent un nom de domaine du fichier T. Le second processus forge une réponses DNS contenant une « fausse » adresse IP associée à ce nom de domaine (cette « fausse » adresse IP est soit indiquée dans le fichier T soit une adresse par défaut attribuée par le second processus). Lorsque le second processus 412 détecte une requête à destination de cette « fausse » adresse IP, il redirige le paquet vers le proxy local Tor avec l’adresse « .onion » correspondante.
Cette fonctionnalité du second processus 412 n’est pas essentielle à l’invention, mais elle permet de rendre la solution proposée plus simple d’emploi pour l’utilisateur, qui ne manipule pas des adresses « .onion » mais des adresses IP ou des noms de domaine, comme il en a l’habitude lorsqu’il utilise l’internet. Mais le processus 412 lui-même est essentiel, notamment pour communiquer avec le contrôleur et recevoir les informations sur les services accessibles.
Agent serveur 42
L’agent serveur 42 s’installe et s’exécute sur une machine du système d’information 20, afin de dissimuler tel ou tel service du système d’information. Par exemple, l’agent serveur 42 est exécuté par le serveur 24 pour dissimuler le service 23. L’agent serveur 42 permet alors de rendre le service accessible à travers l’infrastructure de sécurité 40.
L’agent serveur 42 mémorise un fichier de configuration serveur F.
Le fichier F comporte des données d’authentification du serveur 24, comme par exemple une clé privée, une clé publique et un certificat associé à la clé publique, pour la connexion au contrôleur 44.
La fichier F mémorise également les informations d’identification associées aux utilisateurs pouvant accéder au service 23. Ces informations d’identification comportent de préférence des données d’authentification de chaque client et les droits d’accès associés à ce client.
L’agent serveur 42 mémorise un jeton J2 pour permettre une première connexion au contrôleur 44.
L’agent serveur 42 est composé de deux processus.
Le premier processus 421 est un processus Tor. Il permet de générer les adresses « .onion » des services à dissimuler et de déclarer ces derniers auprès du système de gestion 45 du réseau Darknet 43 pour les rendre accessibles aux utilisateurs autorisés via le Darknet.
Pour ce faire, le premier processus 421 lit le fichier de configuration F détenant ces informations. Tout comme pour l’agent client 41 , ce premier processus 421 exécute un mandataire local pour permettre d’accéder au réseau Darknet 43. Ce premier processus 421 est conforme au proxy local selon l’implémentation Tor.
Le second processus 422 est spécifique à la présente invention. Il permet à un administrateur 28 du système d’information 20 de dialoguer avec le premier processus 421 afin de configurer les services. Avantageusement, l’administrateur 28 accède au second processus 422 comme à un service caché par le Darknet.
Le second processus 422 permet également d’établir et maintenir une connexion avec le contrôleur 44 pour recevoir des informations permettant de mettre à jour le fichier de configuration F.
Contrôleur 44
Le contrôleur 44 est une machine connectée à l’internet.
Le contrôleur 44 comporte une base de données B. Celle-ci contient les informations permettant de mettre à jour les fichiers de configuration client et serveur. La base de données B référence par exemple les utilisateurs, les services et les droits d’accès de ces services par les utilisateurs.
Chaque service offert par le contrôleur 44 est un service caché par le réseau Darknet
43.
Le contrôleur 44 est avantageusement hébergé dans un système d’information différent du système d’information à sécuriser et géré par le fournisseur de cette solution de sécurisation.
Alternativement, il est hébergé directement sur le système d’information de l’organisation qui souhaite utiliser la présente solution de sécurisation afin d’avoir un contrôle optimal de ses données.
Avantageusement, il existe autant de contrôleurs que d’organisations dont on cherche à sécuriser le système d’information afin que les services de ces différentes organisations ne soient pas référencés au sein d’un même contrôleur. Ce partitionnement entre organisations permet d’accroître la sécurité.
Le contrôleur 44 exécute un processus 441 et deux services du type application réseau 442 et 443. Ces deux applications agissent comme des services cachés par le réseau Darknet 43. Ils sont eux-mêmes renseignés au sein du contrôleur 44 et est administrable comme n’importe quel autre service caché.
Le processus 441 est un processus Tor, du type mandataire local. Le processus 441 permet de générer les deux adresses « .onion » des deux services 442 et 443 pour rendre ces services accessibles aux agents distants, clients des services du contrôleur, au travers du réseau Darknet 43.
La première application 442, qui correspond à un service de configuration, écoute un premier port sur la boucle locale pour permettre aux agents de se connecter, s’authentifier et recevoir les informations qui les intéressent, comme par exemple, les adresses « .onion » des services ouverts à l’utilisateur pour l’agent client 41 , ou les noms de domaine et/ou adresses IP pour l’agent client 41 , ou encore les identités des utilisateurs autorisés pour l’agent serveur 42.
De préférence, le contrôleur 44 est administrable au travers de la seconde application 443, qui correspond à un service d’administration, qui est une application web accessible via un second port, distinct du premier port. L’administrateur 28 de l’infrastructure de sécurité connaît l’adresse « .onion » lui permettant d’accéder à la seconde application 443 du contrôleur 44 et de gérer les utilisateurs, les services et les droits d’accès associés, c’est-à-dire de mettre à jour le contenu de la base de données B.
Console d’administration 46.
L’administrateur 28 accède au service d’information 20 et au contrôleur 44 au moyen d’une console 46. La console 46 est un client, similaire au client 10 présenté ci-dessus. Il exécute une application 12’ d’administration du système d’information 20 et du contrôleur 44 pouvant se connecter à travers le réseau Darknet 43 en exécutant un agent client 4 T
(comportant un premier processus 411’ et un second processus 412’) en utilisant les informations regroupées dans un fichier de configuration T’.
PROCEDES
Procédé de connexion à un service caché
En se référant à la figure 2, un procédé de connexion 100 est mis en œuvre pour établir une connexion (par exemple la connexion 101 de la figure 1 ) entre une application d’un client enregistré, comme l’application 12 du client 10, et un service caché, comme le service 23 du serveur 24.
Etape 110 : lorsqu'un utilisateur 1 cherche à utiliser un service caché 23, l’agent client 41 lit le fichier de configuration client T pour extraire l’adresse « .onion » du service auquel il veut accéder. Il établit une connexion avec un point de rendez-vous du Darknet, par exemple le nœud 61. Pour ce faire, l’agent client 41 choisit arbitrairement ce nœud parmi la liste des nœuds qui composent le réseau Darknet 43, cette liste étant publiquement disponible par exemple en interrogeant le système de gestion 45. L’agent client 41 établit ensuite une connexion avec le nœud de rendez-vous choisi. Dans la présente implémentation, cette connexion est avantageusement directe. C’est à dire qu’il n’existe aucun nœud relai du réseau Darknet 43 entre le client 10 et le point de rendez-vous choisi et ce pour permettre de casser l’anonymat du client 10.
Etape 120 : une fois la connexion au réseau Darknet établie, l’agent client 41 demande un accès au service 24 et déclare son point de rendez-vous auprès du système de gestion 45, qui se charge de communiquer à l’agent serveur 42 associé au service demandé, la demande de connexion de la part de l’agent client 41 et l’emplacement du point de rendez-vous choisi. Ce processus, spécifique à l’implémentation Tor n’est pas décrit plus en détails ici.
Etape 130 : lors de la réception d’une demande de connexion au service 23, l’agent serveur 42 vérifie l’identité du client 10 en consultant le fichier de configuration serveur F.
Etape 140 : après vérification positive de l’identité du client ayant initié une demande de connexion, l’agent serveur 42 initie une connexion TCP auprès d’un premier nœud du réseau Darknet, par exemple le nœud 52. Puis l'agent serveur 42 étend la connexion préalablement établie en indiquant au premier nœud relai 52 du circuit d’établir une connexion TCP vers un second nœud relai, choisi par le premier nœud relai, par exemple le nœud 71. Enfin, l’agent serveur 42 étend la connexion une fois de plus, jusqu’au point de rendez-vous 61 . En variante, le circuit entre le système d’information 20 et le point de
rendez-vous peut avoir un autre nombre de sauts (au moins deux pour masquer l’IP du serveur 24).
Etape 150 : les connexions de part et d’autre du point de rendez-vous sont associées par le point de rendez-vous pour permettre à l’agent client 41 et à l’agent serveur 42 d’établir un tunnel sécurisé, et de permettre à l’application 12 exécutée sur le client 10 et au service 23 exécutée par le serveur 24 de communiquer. Le client 10 ne connaît pas l’adresse IP effective du service 23, tandis que le service 23 connaît celle du client qui lui est transmise par le point de rendez-vous.
On constate que le service étant le dernier à établir la connexion, il choisit si oui, ou non, il doit procéder à l’établissement de la connexion jusqu’au point de rendez-vous en fonction de l’identité de l’utilisateur : c’est le principe d’indirection.
Procédé de mise à jour des droits d’un utilisateur et communication de l’adresse d’un service caché
En se référant à la figure 3, les étapes du procédé 200 sont avantageusement mises en œuvre pour renseigner les fichiers de configuration client T et serveur F.
Dans une étape 210, l'administrateur 28 se connecte, via le Darknet, au contrôleur 44 pour accéder au service d’administration des identités et des accès. Il ajoute à la base de données B un droit au client 10 de l’utilisateur 1 pour permettre l’accès au service caché 23. Pour ce faire, la console 46 en tant que client et le contrôleur 44 en tant que serveur d’un service caché réalisent les étapes du procédé de connexion 100 pour établir la liaison 401 . Une fois cette connexion établie, la seconde application 443 permet à l’administrateur d’avoir la main sur la base de données B.
Dans une étape 220, le contrôleur 44 communique l’identité de l’utilisateur et ses droits à l’agent serveur 42. Cette étape est par exemple exécutée sur requête de l’agent serveur 42 lorsqu’il doit vérifier une demande de connexion (étape 130 du procédé 100). Ainsi, l’agent serveur 42 sait qu’il peut autoriser l’établissement d’une connexion jusqu’au point de rendez-vous pour répondre à une demande de connexion du client 10. La communication de cette information est réalisée au moyen d’une connexion 301 à travers le Darknet préalablement établie et maintenue entre l’agent serveur 42, en tant que client, et la première application 442, du contrôleur 44 (circuit 301 sur la figure 1 ), en tant que service caché.
Dans une étape 230, le contrôleur 44 communique l’adresse « .onion » du service 23 à l’agent client 41. Cette communication est réalisée via un tunnel sécurisé préalablement établi et maintenu entre l’agent client 10 de l’utilisateur 1 , en tant que client,
et la première application 442 du contrôleur, en tant que service caché (circuit 201 de la figure 1 ).
Une fois qu’il dispose de l’adresse « .onion » du service 23 cible, le client 10 peut alors établir un tunnel sécurisé jusqu’à ce service et l’agent serveur 42 peut vérifier l’identité du client et établir la connexion jusqu’au point de rendez-vous conformément au procédé 100.
Procédé d’authentification d’un client auprès d’un agent serveur
Afin de s’assurer que la seule connaissance d’une adresse « .onion » ne soit pas suffisante pour réaliser une connexion avec un service caché, on prévoit avantageusement la mise en œuvre des étapes du procédé 300 pour permettre l’authentification d’un client 10 par l’agent serveur 42 associé au service 23 (étape 130 du procédé 100).
Ce procédé élémentaire 300 est illustré par la figure 4.
Dans une étape 310, l’agent serveur 42 rend disponible le service applicatif 23 sur le Darknet 43, en générant une adresse « .onion » pour le service 23, et enregistre le service 23 auprès du système 45 du réseau Darknet 43. Cette fonctionnalité est native à l’implémentation Tor selon la version en vigueur et n’est pas modifiée ici.
Dans une étape 320, l’agent serveur 42 établit et maintient une connexion 301 , à travers le réseau Darknet 43, avec la première application 442 du contrôleur 44 des accès et identités.
Dans l’étape 330, l’agent serveur 42 communique également au contrôleur 44 l’adresse « .onion » qu’il a générée pour le service 23.
Dans l’étape 340, le contrôleur 44 communique à l’agent serveur 42 l’ensemble des identités des utilisateurs ayant le droit d’établir une connexion avec le service 23 (ceci correspond à l’étape 220 du procédé de la figure 3). A chaque modification de droit dans la base de données B, le contrôleur 44 avertit l’agent serveur 42.
Dans une étape 350, lors de la réception d’une requête de connexion de la part de l’agent client 41 , l’agent serveur 42 vérifie que le client 10 détient effectivement le droit de se connecter. Si oui, il établit une connexion vers le point de rendez-vous choisi par l’agent client 41 , en suivant le principe d’indirection (étape 140 du procédé de la figure 1 ).
Il est à souligner que l’étape 330 permet de centraliser les adresses « .onion » des services d’une organisation donnée au sein de la base de données B mémorisée par le contrôleur 44. Le contrôleur 44 référence ainsi les utilisateurs de l’organisation, les services et les droits d’accès. Cela permet au contrôleur 44, au moyen du service de configuration, d’indiquer aux clients les adresses « .onion » des services accessibles, comme cela est décrit en référence à la figure 5. Au contraire, dans l’implémentation Tor selon la version en
vigueur, les adresses « .onion » sont considérées comme des informations hors du cadre du standard, qu’il est de la responsabilité des administrateurs de services de communiquer à leurs utilisateurs.
Première connexion par jeton
Etant donné que les agents client 41 et serveur 43 ont besoin de connaître l’adresse « .onion » de la première application 442 du contrôleur 44, ils doivent détenir certaines informations de configuration initiale, comme un certificat, une clé et l’adresse « .onion » du contrôleur 44.
Afin de faciliter le dépôt de ces informations de configuration initiale sur la machine sur laquelle l’agent est exécuté, l’agent peut avantageusement récupérer ces informations directement auprès du contrôleur 44 en mettant en œuvre les étapes du procédé 400 de la figure 5.
Dans une étape 410, l’utilisateur (respectivement l’administrateur du service à cacher) reçoit un jeton d’initialisation. Celui-ci est par exemple composé de l’adresse « .onion »du contrôleur 44 et d’un identifiant unique. Ce couple d’informations est par exemple généré par le contrôleur 44 sur demande de l’administrateur 28. Ce couple d’informations est communiqué à l’utilisateur 1 (ou à l’administrateur du service à cacher) par un moyen de communication annexe avec le niveau de sécurité adapté, par exemple par la transmission d’un courrier électronique crypté comportant le jeton.
Dans une étape 420, au moyen de ce jeton, l’agent client 41 (respectivement l’agent serveur 42) se connecte au contrôleur 44. Il lit l’adresse « .onion » du service de configuration du contrôleur 44, indiquée par le jeton, se connecte, via le réseau Darknet, au service de configuration du contrôleur 44, et transmet au contrôleur 44 l’identifiant unique indiqué par le jeton.
En retour, dans une étape 430, service de configuration du contrôleur 44 génère un certificat et une clé et transmet ces données d’authentification à l’agent client (ou à l’agent serveur). Le jeton est alors « consommé » (invalidé) par le contrôleur 44. Un jeton n’est valide que pendant une durée limitée et n’est utilisable qu’une seule fois pour garantir la sécurité.
Par la suite, dans une étape 440, grâce à ces informations de configuration, qui sont mémorisées dans le fichier T (respectivement dans le fichier F), l’agent client 41 (respectivement l’agent serveur 42) a la possibilité d’établir une nouvelle connexion avec le service de configuration du contrôleur 44 et de s’authentifier auprès du contrôleur 44 en utilisant les informations du fichier T (respectivement du fichier F). De préférence, un agent maintient cette connexion avec le contrôleur.
Dans une étape 450, l’agent client 41 récupère, du service de configuration du contrôleur 44, des informations de configuration générales comme les adresses « .onion » des services cachés qui lui sont ouverts. Il stocke ces informations dans le fichier T. L’agent serveur 42 récupère, du service de configuration du contrôleur 44, les informations de configuration générales comme l’identification de chaque utilisateurs. Il stocke ces informations dans le fichier F.
Enfin, dans une étape 460, le client 10 accède au service applicatif caché désiré en utilisant son adresse « .onion », en négociant un point de rendez-vous avec le réseau Darknet, puis en établissant une connexion avec le service caché via le processus usuel de l’implémentation Tor (mise en œuvre du procédé 100).
Avec le procédé 400, les agents client et serveur connaissent l’adresse « .onion » du contrôleur 44.
À tout moment, dès qu’une modification est réalisée sur des droits d’accès dans la base de données B, le contrôleur 44 indique cette modification aux clients concernés : une nouvelle adresse « .onion » est disponible, une adresse « .onion » doit être invalidée, un utilisateur a droit d’accéder à tout ou partie d’un service caché ou au contraire n’a plus le droit d’accéder à tout ou partie d’un service caché.
AVANTAGES
L’invention porte donc sur une infrastructure fondée sur un réseau Darknet privé permettant de supprimer l’exposition des services sur internet.
L’infrastructure Darknet est complétée par l’addition d’un contrôleur offrant différents services cachés pour augmenter la sécurité : distribution sécurisée des adresses oignons vers les clients (de préférence aux seuls clients autorisés) ; distribution des informations d’identification des clients vers les serveurs, pour renforcer l’authentification des clients requérant un accès à un service fourni par un serveur.
L’implémentation Tor d’une infrastructure Darknet est avantageusement modifiée pour supprimer l’anonymat des utilisateurs, tout en gardant celui des services cachés.
Elle est également avantageusement modifiée pour rendre le réseau Darknet privé, c’est-à-dire empêcher d’autres acteurs que l’administrateur d’y ajouter des machines.
Les agents client permettent avantageusement aux utilisateurs d’accéder aux services cachés comme s’ils accédaient à des services exposés sur internet.
L’infrastructure proposée présente les propriétés suivantes :
- Il est techniquement impossible pour quiconque ayant accès à une partie ou à l’intégralité des machines de l’infrastructure d’établir une connexion avec les services
cachés sans détenir les droits sur ces machines spécifiés dans la base de données de management de l’organisation.
- Il est impossible de déterminer les adresses IP publiques des services cachés.
- La console d’administration n’est plus exposée sur l’Internet et utilise elle-même l’infrastructure pour se dissimuler.
Ces propriétés font que l’infrastructure est une infrastructure respectant le modèle ZTNA.
Claims
1 . Infrastructure de sécurité, destinée à être déployée dans une architecture s’appuyant sur l’internet, pour sécuriser une connexion entre un client (10) connecté à l’internet (30) d’une part et un serveur (24) d’un système d’information (20) connecté à l’internet d’autre part, le système d’information (20) mettant à disposition un service applicatif (23), l’infrastructure de sécurité, en tant qu’infrastructure Darknet, comportant :
- un réseau Darknet (43), en superposition de l’internet (30) ;
- un agent client (41 ), exécuté par le client (10) pour accéder au service applicatif (23), le service applicatif étant caché par réseau Darknet (43), l’agent client mémorisant un fichier de configuration client (T) ; et,
- un agent serveur (42), exécuté sur le serveur (24) du système d’information (20), pour permettre un accès au service applicatif (23) depuis le réseau Darknet (43), l’agent serveur mémorisant un fichier de configuration serveur (F), l’infrastructure de sécurité étant caractérisée en ce qu’elle comporte, en outre, un contrôleur (44) offrant un service de configuration, qui est caché par le réseau Darknet, le contrôleur comportant une base de données (B) stockant des informations de configuration, le service de configuration étant accessible depuis le réseau Darknet (43) par l’agent client (41 ), respectivement par l’agent serveur (42), pour recevoir les informations de configuration client, respectivement serveur, permettant la mise à jour du fichier de configuration client, respectivement serveur, les informations de configuration client comportant au moins un adresse sur le réseau Darknet du service applicatif pour permettre au client d’accéder, via le réseau Darknet, au service applicatif (23), et les informations de configuration serveur comportant au moins des informations d’identification permettant au serveur d’identifier le client requérant un accès au service applicatif (23).
2. Infrastructure selon la revendication 1 , dans laquelle un agent parmi l’agent client et l’agent serveur mémorise un jeton (J1 , J2) permettant audit agent une connexion initiale, via le réseau Darknet (23), au service de configuration du contrôleur (44), le service de configuration étant adapté pour fournir, lors de cette première connexion, à l’agent des données d’authentification, l’agent étant adapté pour établir une nouvelle connexion, à travers le réseau Darknet, avec le service de configuration du contrôleur en utilisant les données d’authentification fournies.
3. Infrastructure selon l’une quelconque des revendications 1 à 2, comportant une console d’administration (46) adaptée pour administrer le contrôleur (44)
et avantageusement l’agent serveur (42), la console d’administration exécutant un agent pour accéder, à travers le réseau Darknet (43), à un service d’administration offert par le contrôleur et avantageusement par l’agent serveur, le service d’administration étant un service caché par le réseau Darknet.
4. Infrastructure selon l’une quelconque des revendications précédentes, fondée sur une implémentation Tor de l’infrastructure Darknet.
5. Infrastructure selon l’une quelconque des revendications précédentes, dans laquelle le réseau Darknet est un réseau privé.
6. Procédé de connexion, mis en œuvre dans une infrastructure de sécurité selon l’une quelconque des revendications 1 à 5, pour sécuriser une connexion entre un client (10) connecté à l’internet (30) d’une part et un serveur (24) d’un système d’information (20) connecté à l’internet d’autre part, le système d’information (20) mettant à disposition un service applicatif (23), le procédé de connexion consistant à :
- renseigner une base de donnée du contrôleur (44), la base de données (B) stockant des informations de configuration pour le client et pour le serveur, les informations de configuration client comportant au moins un adresse sur le réseau Darknet du service applicatif pour permettre au client d’accéder, via le réseau Darknet, au service applicatif (23), et les informations de configuration serveur comportant au moins des informations d’identification permettant au serveur d’identifier le client requérant un accès au service applicatif (23) ;
- mettre à jour un fichier de configuration client (T) de l’agent client, respectivement un fichier de configuration serveur (F) de l’agent serveur, l’agent client (41), respectant l’agent serveur, accédant, à travers le réseau Darknet, à un service de configuration offert par le contrôleur, pour recevoir les informations de configuration client, respectivement serveur, le service de configuration étant caché par le réseau Darknet ;
- établir (110) par l’agent client (41 ) une connexion avec un nœud dit « point de rendez- vous » du réseau Darknet (43), en utilisant les informations contenues dans le fichier de configuration client ;
- requérir (120) par l’agent client (41 ) un accès au service applicatif (23) auprès du réseau Darknet (43) en déclarant l’identifiant du nœud « point de rendez-vous » ;
- vérifier (130) par l’agent serveur (42) d’identité du client (10) sur lequel est exécuté l’agent client (41 ) en utilisant les informations d’identification contenues dans le fichier de configuration serveur ; et, en cas de vérification positive,
- établir (140) par l’agent serveur (42) une connexion avec le nœud « point de rendez- vous » du réseau Darknet (43) ;
- associer (150) les connexions de part et d’autre du nœud « point de rendez-vous » pour établir une communication (101 ) entre le client et le serveur.
7. Procédé selon la revendication 6, dans lequel, pour établir par un agent parmi l’agent client et l’agent serveur une connexion avec le service de configuration du contrôleur (44), le procédé consiste, en outre, à :
- recevoir (410) par l’agent un jeton de connexion indiquant une adresse sur le réseau Darknet du service de configuration offert par le contrôleur et un identifiant ;
- établir (420) par l’agent une connexion initiale au service de configuration du contrôleur en utilisant l’adresse du service de configuration indiquée dans le jeton et identifier par le contrôleur l’agent en utilisant l’identifiant indiqué dans le jeton ;
- fournir (430) par le service de configuration contrôleur, à l’agent des données d’authentification ; et,
- établir (440) par l’agent une nouvelle connexion au service de configuration du contrôleur en utilisant les données d’authentification.
8. Produit programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un client (10), un serveur (24) et un contrôleur (44) d’une infrastructure selon l’une quelconque des revendications 1 à 5, mettent en œuvre un procédé selon l’une quelconque des revendications 6 à 7.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FRFR2205225 | 2022-05-31 | ||
FR2205225A FR3136075B1 (fr) | 2022-05-31 | 2022-05-31 | Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés. |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023232888A1 true WO2023232888A1 (fr) | 2023-12-07 |
Family
ID=83505710
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2023/064581 WO2023232888A1 (fr) | 2022-05-31 | 2023-05-31 | Infrastructure de sécurité; procédé et produit programme d'ordinateur associés |
Country Status (2)
Country | Link |
---|---|
FR (1) | FR3136075B1 (fr) |
WO (1) | WO2023232888A1 (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN119135552A (zh) * | 2024-11-15 | 2024-12-13 | 北京哈工创新计算机网络与信息安全技术研究中心 | 一种基于多粒度仿真的Tor网络攻防实验平台 |
-
2022
- 2022-05-31 FR FR2205225A patent/FR3136075B1/fr active Active
-
2023
- 2023-05-31 WO PCT/EP2023/064581 patent/WO2023232888A1/fr unknown
Non-Patent Citations (5)
Title |
---|
GARETH OWEN ET AL: "Empirical analysis of Tor Hidden Services", IET INFORMATION SECURITY, THE INSTITUTION OF ENGINEERING AND TECHNOLOGY, MICHAEL FARADAY HOUSE, SIX HILLS WAY, STEVENAGE, HERTS. SG1 2AY, UK, vol. 10, no. 3, 1 May 2016 (2016-05-01), pages 113 - 118, XP006105557, ISSN: 1751-8709, DOI: 10.1049/IET-IFS.2015.0121 * |
LOESING KARSTEN: "Privacy-enhancing technologies for private services", 24 April 2009 (2009-04-24), XP093012720, Retrieved from the Internet <URL:https://www.freehaven.net/anonbib/cache/loesing2009thesis.pdf> [retrieved on 20230110] * |
NURMI JUHA ET AL: "Observing Hidden Service Directory Spying with a Private Hidden Service Honeynet", 2016 11TH ASIA JOINT CONFERENCE ON INFORMATION SECURITY (ASIAJCIS), IEEE, 4 August 2016 (2016-08-04), pages 55 - 59, XP033023342, DOI: 10.1109/ASIAJCIS.2016.31 * |
PENGPENG WANG ET AL.: "Simulation of Dark Network Scene Based on the Big Data Environment", INFORMATION TECHNOLOGY AND ELECTRICAL ENGINEERING 2018, 7 December 2018 (2018-12-07), pages 1 - 6, XP058427872, DOI: 10.1145/3148453.3306250 |
PENGPENG WANG ET AL: "Simulation of Dark Network Scene Based on the Big Data Environment", INFORMATION TECHNOLOGY AND ELECTRICAL ENGINEERING 2018, ACM, 2 PENN PLAZA, SUITE 701NEW YORKNY10121-0701USA, 7 December 2018 (2018-12-07), pages 1 - 6, XP058427872, ISBN: 978-1-4503-6352-5, DOI: 10.1145/3148453.3306250 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN119135552A (zh) * | 2024-11-15 | 2024-12-13 | 北京哈工创新计算机网络与信息安全技术研究中心 | 一种基于多粒度仿真的Tor网络攻防实验平台 |
Also Published As
Publication number | Publication date |
---|---|
FR3136075B1 (fr) | 2024-11-29 |
FR3136075A1 (fr) | 2023-12-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2819052B1 (fr) | Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique | |
FR2801754A1 (fr) | Methode pour assigner une double adresse ip a un poste de travail relie a un reseau de transmission de donnees ip | |
EP1562343A1 (fr) | Procédé et système de gestion d'autorisation d'accès d'un utilisateur au niveau d'un domaine administratif local lors d'une connexion de l'utilisateur à un réseau IP | |
FR3007167A1 (fr) | Procede d'authentification d'un terminal par une passerelle d'un reseau interne protege par une entite de securisation des acces | |
EP4066461A1 (fr) | Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés | |
CH718976A2 (fr) | Gestion des pares-feux d'entreprise et isolement du réseau. | |
EP3695571B1 (fr) | Dispositif et procédé de transmission de données | |
WO2023232888A1 (fr) | Infrastructure de sécurité; procédé et produit programme d'ordinateur associés | |
EP3857848B1 (fr) | Procédé d'allocation d'un identifiant à un noeud client, procédé d'enregistrement d'un identifiant, dispositif, noeud client, serveur et programmes d'ordinateurs correspondants | |
WO2018130796A1 (fr) | Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés | |
EP3811587A1 (fr) | Procédé de modification de messages par un équipement sur un chemin de communication établi entre deux noeuds | |
EP3788762A1 (fr) | Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip | |
EP4367831A1 (fr) | Procede d'etablissement authentifie d'une connexion entre un equipement raccorde a au moins un reseau de communication et un serveur d'un fournisseur de services et dispositifs correspondants | |
WO2012156365A1 (fr) | Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants | |
EP3815335A1 (fr) | Procédés de vérification de la validité d'une ressource ip, serveur de contrôle d'accès, serveur de validation, noeud client, noeud relais et programme d'ordinateur correspondants | |
WO2020065234A1 (fr) | Procédés de protection d'un domaine client, nœud client, serveur et programmes d'ordinateur correspondants | |
EP3149902B1 (fr) | Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client | |
EP4210277B1 (fr) | Procédé de création d'un canal de communication entre une application locale et une application saas, et procédé et système de communication entre lesdites applications | |
FR3145253A1 (fr) | Procédé de révocation d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants | |
Rafiee et al. | Towards privacy awareness in future internet technologies | |
Müller | Past, Present and Future of Tor Hidden Services | |
WO2023117802A1 (fr) | Procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique, dispositifs et signal correspondants | |
WO2023083769A1 (fr) | Procédé de traitement d'au moins un paquet de données, dispositif et système associés. | |
FR3137238A1 (fr) | Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants | |
FR3093882A1 (fr) | Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants. |
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: 23729418 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |