[go: up one dir, main page]

WO2016003860A1 - Communications de réseau sécurisé dans un dispositif mobile sur ipsec - Google Patents

Communications de réseau sécurisé dans un dispositif mobile sur ipsec Download PDF

Info

Publication number
WO2016003860A1
WO2016003860A1 PCT/US2015/038239 US2015038239W WO2016003860A1 WO 2016003860 A1 WO2016003860 A1 WO 2016003860A1 US 2015038239 W US2015038239 W US 2015038239W WO 2016003860 A1 WO2016003860 A1 WO 2016003860A1
Authority
WO
WIPO (PCT)
Prior art keywords
vdr
mobile device
broker
vpn
mobile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2015/038239
Other languages
English (en)
Inventor
Robert A. Johnson
James TROCKI
Mark K. Vallevand
Steven L. Rajcan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Unisys Corp
Original Assignee
Unisys Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Unisys Corp filed Critical Unisys Corp
Priority claimed from US14/753,146 external-priority patent/US9794225B2/en
Publication of WO2016003860A1 publication Critical patent/WO2016003860A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/0272—Virtual private networks
    • 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
    • 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/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls

Definitions

  • the present application relates generally to secured communications and storage systems, and in particular to secure network communications in a mobile device over IPSec.
  • IPsec Internet Protocol Security
  • IP Internet Protocol
  • IPsec includes protocols for establishing authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session.
  • IPsec is an end-to-end security scheme of the Internet Protocol Suite.
  • IPsec operates in the Internet Layer rather than operating in the upper layers of the TCP/IP model.
  • IPsec protects any application traffic across an Internet Protocol (IP) network. Applications do not need to be specifically designed to use IPsec, whereas TLS/SSL is required to be designed into an application to protect the application protocols.
  • IPsec operates in both IPv4 and IPv6-enabled networks.
  • IPsec is not without drawbacks.
  • Existing IPsec-enabled systems typically negotiate to create IPsec tunnels, or secure tunnels, on a point-to-point basis, rather than allowing for data access by multiple entities within the same "community of interest".
  • IPsec is only available on some modern computing systems, and may be limited in availability in different types of systems, such as mobile devices.
  • different implementations of IPsec on different types of computing systems are handled differently, leading to inconsistencies in connection parameters.
  • IPsec is built based on a premise that two computing systems can negotiate security parameters; when two such systems intend to form a secure tunnel, that tunnel is established through use of an IKE key exchange, which requires a response to an initial transmission.
  • IKE key exchange which requires a response to an initial transmission.
  • a method of communicating with secure endpoints included within a secured network from a mobile device external to the secured network includes initiating a VPN-based secure connection to a VPN appliance, and initializing a stealth-based service on the mobile device.
  • the method further includes transmitting user credential information from the mobile device to a VDR broker via the VPN appliance, and receiving status information from the VDR broker identifying a VDR associated with the mobile device and providing a connected status.
  • the method also includes communicating with one or more secure endpoints within the secured network via a VPN connection to the VDR via the VPN appliance and through the VDR to the one or more secure endpoints within a community of interest based on the user credential information transmitted to the VDR broker.
  • a method of enabling communication between a mobile device and one or more secure endpoints included within a secured network includes receiving user credentials from a mobile device at a VDR broker within a gateway, and allocating a VDR at the gateway.
  • the method also includes retrieving a wrapping key associated with the VDR, and transmitting a tuples request to an authentication server from the VDR broker, the tuples request including the user credentials.
  • the method further includes receiving from the authentication server COIs wrapped with the wrapping key associated with the VDR, the COIs based on the user credentials, and providing configuration information to the VDR [0025]
  • a system for enabling communication between a mobile device and one or more secure endpoints included within a secured network includes a mobile gateway communicatively connectable to a mobile device via a tunneled connection.
  • the mobile gateway includes a VDR broker configured to allocate VDRs to mobile devices based on authentication credentials received from the mobile devices and obtain key information to provide to the allocated VDRs for use in secure communications within the secured network.
  • the mobile gateway further includes one or more VDRs associated with the mobile device and providing proxied secure communications using the key information obtained from the authentication server based on the authentication credentials provided by the mobile device.
  • Figure 1A illustrates a generalized network in which communication is enabled between a mobile device and one or more secure endpoints included within a secured network
  • Figure IB illustrates components of a VDR broker included in the mobile gateway illustrated in Figure 1 A, and useable to establish a virtual data relay (VDR) useable to enable communication between a mobile device and one or more secure endpoints included within a secured network;
  • VDR virtual data relay
  • Figure 2 illustrates a state diagram showing connectivity states of a mobile gateway for a particular enabled network connection between a mobile device and one or more secure endpoints included within a secured network;
  • Figure 3 illustrates an arrangement allowing a mobile device to connect to a plurality of different communities of interest, according to an example embodiment
  • Figure 4 illustrates a flowchart of a method for enabling communication between a mobile device and one or more secure endpoints included within a secured network
  • Figures 5A-5B illustrate an event sequence occurring at a mobile gateway to establish a VDR used for communication between a mobile device and one or more secure endpoints included within a secured network, according to an example embodiment
  • Figures 6A-6B illustrate a sequence of communications among devices in establishing communications between a mobile device and one or more secure endpoints within a secured network, according to an example embodiment
  • Figure 7 illustrates a sequence of communications among devices in performing a logoff operation for a first user, and establishing communications between a mobile device and one or more secure endpoints within a secured network for a second user, according to an example embodiment
  • Figure 8 illustrates a sequence of communications among devices in performing a connection process in which a YPN error occurs, according to an example embodiment
  • Figure 9 illustrates a sequence of communications among devices in performing a connection process in which a Stealth tunnel error occurs and is closed, according to an example embodiment
  • Figure 10 illustrates an arrangement of the network of Figure 1 according to a further example embodiment providing high-availability connection for mobile devices to a Stealth-enabled network;
  • Figure 11 illustrates an example computing system in which aspects of the present disclosure can be implemented
  • Figure 12 illustrates an example virtualization environment implemented on a computing system, illustrating a mechanism by which private-domain and cloud-based virtual machines can be implemented.
  • Figure 13 illustrates an example multi-user computing arrangement illustrating shared computing resources across different partitions and/or virtual machines, according to example embodiments.
  • the present disclosure relates to improvements to systems and methods for securing endpoints and communication channels, such as the Stealth secure communications and storage system of Unisys Corporation of Blue Bell, Pennsylvania.
  • endpoints e.g., client or server computing systems
  • data to be transmitted among endpoints is encrypted such that (1) no computing system other than the sender and intended recipient can view the contents of the encrypted message(s)
  • the messages are configurable such that message packets themselves are split among different packets and optionally transmitted along different transmission paths between computing systems, to ensure receipt of the secured communications at a receiving endpoint That receiving endpoint can then reconstruct the message based on one or more such received split and encrypted messages.
  • the present disclosure specifically describes aspects of secure communications and secure computing systems that provide for a flexible manner in which mobile devices external to a secured network, such as a network secured with Stealth technology, can remotely connect to and securely communicate with endpoints within that secured network.
  • a secured network such as a network secured with Stealth technology
  • the present application describes methods and systems by which specific devices, users, or applications themselves may be specifically associated with a group of affiliated computing resources such that only those resources within the secured network are visible to that associated device, user, or application. Other endpoints or computing resources within the secured network remain present, but are entirely opaque to the mobile device if not within the same community of interest,.
  • the present disclosure provides an additional layer of security in addition to traditional VPN connectivity, which is traditionally controlled or secured only at the level of user/device.
  • the network [0045] a generalized network [00 in which communication is enabled between a mobile device and one or more secure endpoints included within a secured network is shown.
  • the network [00 includes a mobile device 102 communicatively connected, via a public network 110, to a VPN server 104 managed by a secured entity.
  • the VPN server 104 allows for communication via a trusted subnet 120 to a mobile gateway 106.
  • the mobile device 102 generally corresponds to any type of mobile device, such as a mobile phone, tablet, laptop, or other type of mobile device which may be used to connect to a secured network from a variable location and/or subnetwork.
  • a mobile phone and tablet devices such a device may be an iOS-based device provided by Apple Corporation of Cupertino, California, or an Android-based device provided by any of a number of equipment-manufacturers, and operating using a variant of the Android operating system provided by Google, Inc. of Mountain View, California.
  • Other types of mobile operating systems could be used as well (e.g., Blackberry, Microsoft's Windows Phone OS, or other operating systems).
  • the mobile device 102 either has a native IPsec implementation allowing it to communicate with a VPN server via an IPsec- based connection, or is capable of having installed thereon an application mat manages such a secured connection over a public network. Consequently, the VPN server 104 provides a location at which the mobile device 102 can establish a secure connection to the enterprise, and which relays messages to the mobile gateway which effectively proxies the mobile device within the secure network, as discussed in further detail below.
  • the VPN server 104 connects to an external network which is also accessible by the mobile device 102.
  • the VPN server 104 authenticates and establishes an IPsec tunnel between itself and the mobile device 102, assigning it an IP address and subsequently routing traffic to the trusted subnet 120.
  • the mobile gateway 106 generally receives messages from the VPN server 104, relayed from the mobile device 102, via a portion of the enterprise network shown as a trusted subnet 120, which is dedicated to secure message routing between one or more VPN servers 104 and mobile gateways 106.
  • the trusted subnet 120 may pass messages in cleartext or encrypted form, but in a manner dedicated to such interface communications with devices located remotely from the enterprise.
  • the trusted subnet may be a physical network connecting devices or a virtual network connecting software within an OS instance or a combination of the two. In all cases the trusted subnet 120 is isolated from the outside network and the Stealth network 130.
  • the mobile gateway 106 is communicatively connected to a Stealth network 130.
  • the Stealth network 130 generally corresponds to a network managed within an enterprise, and which includes a plurality of Stealth network endpoints 132a-c, an authentication server 134, and a licensing server 136.
  • the Stealth network 130 generally implements Stealth-based communications among endpoints within the Stealth network 130, as discussed in the applications incorporated by reference above.
  • the Stealth network 130 can be implemented using one or both of an IPsec-based Stealth implementation and a multi-level secure tunneling protocol (MLSTP)-based Stealth implementation, as is also described in the applications incorporated by reference above.
  • MLSTP multi-level secure tunneling protocol
  • the mobile gateway 106 includes a VDR broker 112 and a plurality of VDRs 114a-b.
  • the VDR broker 112 interacts with the VPN server 104 and an authentication server 134, and the resources which instantiate instances of a virtual data relay (VDR), to establish routing of traffic to effectively allow a mobile device to participate in the Stealth network 130.
  • VDR virtual data relay
  • the VDR broker 112 acquires a Stealth license; during the authentication and authorization process of each mobile endpoint, the authorization manager of the VDR broker 112 will identify itself to the authentication server 134 as a VDR broker 112 for a mobile device in an XML-based tuples request (discussed in further detail below), and identifies the authenticating user via HTTP. The authentication server 134 will then indicate to the VDR broker 112 that a Stealth Mobile license is available for use.
  • VDR broker 112 will not service client connections from mobile devices without first securing appropriate licenses, from the authentication server 134 and/or licensing server 136.
  • the VDRs 114a-b operate as proxies for the mobile devices 102 with which they are associated.
  • an instance of a VDR exists for each IPsec connection established by the VPN server 104.
  • each device will be associated with a different VDR 114.
  • different applications on the mobile device 102 are each associated with different VPN-based connectivity, and have different security credentials.
  • different VDRs (shown as VDRs 114a-b) are associated with different applications on the same mobile device 102.
  • each VDR 114 hosts a Stealth network endpoint. The endpoint has been authenticated by the authentication server 134.
  • Traffic routes are established allowing traffic to flow between a stealth network endpoint 132 and the mobile device 102, based on the stealth network endpoint and the associated application (or device, or user, based on the level of granularity of security authorization as implemented), in particular embodiments, application-level authentication is used to the exclusion of device-level authentication, requiring a user to authenticate himself/herself within each application seeking a secured connection to Stealth network endpoints 132.
  • the IPsec-based Stealth solution can be employed in either an entirely IPsec-based secure network, or within an existing Stealth network employing a traditional bit-based splitting and encrypting/dercrypting arrangement, which utilizes an existing multi-level secure transport protocol (MLSTP) secure communications construct.
  • MLSTP multi-level secure transport protocol
  • all endpoints in the Stealth network are required to be licensed with a Stealth license that supports earlier versions of the Stealth security protocol.
  • a Stealth appliance may be used, and all licensing and logging is provided through the Stealth appliance (or team of appliances).
  • a mixed Stealth configuration may be required when the IPsec- based system is deployed in an existing Stealth network in which endpoints are already running a previous Stealth configuration, or when the existing (or new) Stealth network must support otherwise unsupported endpoints (e.g., Windows XP, Windows 2003).
  • endpoints e.g., Windows XP, Windows 2003.
  • the VPN server 104 will perform the IPsec authentication and tunnel address assignment with participation by the VDR broker 112. Accordingly, mobile device applications will connect to the VPN server 104 using a user ID for an IPsec authentication, which will also subsequently used for Stealth authentication via the authentication server 134.
  • the VDR broker 112 operates on an enterprise Linux-based system, with each of a plurality of managers instantiated thereon executing as separate programs in separate processes.
  • the VDR broker 112 can be deployed as a bootable image that can be deployed on a bare metal computing system or virtual machine guest on a computing device, such as the devices illustrated in Figures 11-13, below.
  • Various messages handled by the VDR broker 112, and in particular the managers included therein, can be implemented using named pipes, with messages represented in structures that are decodable to function parameters that can be consumed by the event managers.
  • the VDR broker 112 includes an authentication manager 113, a VPN manager 115, a VDR manager 116, a client application manager 117, an event manager 118, and a license manager 119.
  • the authentication manager 113 operates to, in example embodiments, authenticate VPN user and client application credentials with the Stealth-enabled network, for example by connecting to the authentication server 134.
  • the authentication manager 113 can do so, for example in response to a request generated by the event manager 118.
  • the authentication manager can further obtain Stealth authentication and authorization key materials, and return them to the event manager 118.
  • the authentication manager 113 is configured to abstract such communication systems into a single, unified view presented to the mobile device 102.
  • an API library can be used to connect to the authentication server 134 to authenticate user/application credentials.
  • the VPN manager 115 in the embodiment shown, is configured to receive client tunnel connection indications from the VPN server 104, and reports the information to the event manager 118.
  • the VPN manager is configured to receive client tunnel disconnection indications from the VPN server 104 and reports them to the event manager 118 as well.
  • the VPN manager 115 is also configured to close a client tunnel in the VPN concentrator upon request from the event manager 118, and manages different types of VPN and abstracts them into a single view for management purposes.
  • an SSII-based library can be used by the VPN manager 115 to issue command line operations to the VPN server 104, to explicitly issue connection closures to mobile devices connected via such a VPN server.
  • the VDR manager 116 in the embodiment shown, is configured to start and shut down VDRs 114, as well as handling requests from the broker.
  • the VDR manager 116 is further configured to create new VDR 114 and return its IP addresses.
  • the VDR manager 116 is also configured to delete old VDRs, and manage an available VDR pool, to the extent a maximum number or available number of VDRs is provided at the mobile gateway 106.
  • the VDR manager 116 creates and/or starts new VDRs 114 when needed and assigns IP addresses and other configuration parameters to those VDRs.
  • the VDR manager also manages different versions of VDRs, for example based on types of connectivity, and abstracts them into a single view.
  • the VDR manager 116 is instantiated using a shell script within the VDR broker 112, and initiates a container having a configuration file.
  • the VDR manager 116 can be initialized to instantiate a master VDR as well as one or more internal VDR pools and lists, and initialize individual VDRs for use.
  • the VDR manager 116 can associate IP addresses, hardware addresses, and other physical resources (routing, packet forwarding parameters) to the various VDRs.
  • the VDR manager 116 maintains a set of life- cycle states of VDRs, including a starting state, a running state, a freezing state, a frozen state, an unfreezing state, a stopping state, and an error state.
  • the starting state represents a VDR cloned from a master VDR, which initializes hardware resources and causes the VDR to join a pool as a running VDR.
  • the VDR is then initialized as useable within a stealth network, and enters a freezing state, which places the VDR in the pool of available VDRs (discussed below), in a frozen state.
  • the VDR manager 116 indicates that the VDR is in an unfreezing state.
  • the stopping state manages client requests to stop a VDR, which corresponds to the termination occurring in Figure 2 (and tracked by the event manager 118) below.
  • An error state indicates that an uncorrectable error has occurred within the VDR, causing it to be terminated and ceasing to exist (allowing a new VDR to be re-instantiated).
  • the client application manager 117 in the embodiment shown, is configured to receive Stealth user credentials from a mobile client application, and receives status update requests from such an application. Likewise, the client application manager 117 can be configured to send status update requests to an application on a mobile device, and manage different types of client applications for abstracting to a single view for management purposes as well.
  • the event manager 118 in the embodiment shown, is configured to manage the state of each client connection.
  • Example states of client connections are described in an example embodiment below, in connection with Fig. 2.
  • the event manager 118 is further configured to receive and act upon events posted by the other modules, as also described below.
  • the license manager 119 in the embodiment shown, is configured to obtain a fixed count of Stealth Mobile licenses from a Stealth license gateway, and maintain a license tunnel to the license gateway on behalf of each of the VDRs 114 at the mobile gateway 106.
  • the license manager 119 is further configured to report license tunnel and license allocation status to the event manager 118.
  • the event manager 118 manages a VDR table 131 mat tracks a state of each client connection.
  • the VDR table 131 can include, for example, various user and connectivity parameters, such as a VPN User ID, a VPN assigned IP address, a VPN Session ID, a VDR Session ID, a VDR IP address, a Stealth User ID, a start time, a keep alive (last received) time, a state (e.g., pending, open, close, error), and a list of IDs for communities of interest associated with the particular VDR, defining the endpoints with which that VDR can connect or to which the VDR (and associated mobile device 102) is visible.
  • various user and connectivity parameters such as a VPN User ID, a VPN assigned IP address, a VPN Session ID, a VDR Session ID, a VDR IP address, a Stealth User ID, a start time, a keep alive (last received) time, a state (e.g., pending, open,
  • the VDR broker 112 manages a plurality of events and associated states for each connection to a mobile device application. Events can include, for example, an access request message receipt, a VPN tunnel up or down message, a VDR down event, a Stealth tunnel down event, a Stealth TUN down event, or a license lost event. Such events can be triggered, typically, by external systems transmitting messages to the VDR broker 112.
  • the VDR broker 112 can take a plurality of different actions relative to such messages received, such as adding a new VDR, deleting an old VDR, performing a status query, generating an administrative notification, retrieving a wrapping key from an active VDR, or sending community of interest (COI) keys to a VDR.
  • the VDR broker 112 manages VDR states for each VDR, as noted below.
  • VDR states can include, for example, a null session state 202 (referred to as SESS_NONE), a VDR request state 204 (SESS_REQ_VDR), an assigned VDR state 206 (SESS_ASSIGNED_VDR), a VDR provisioning request state 208 (SESS_COI_PROV_REQ), and a VDR active state 210 (SESS_COI_ACTIVE).
  • SESS_NONE a null session state 202
  • SESS_REQ_VDR VDR request state 204
  • SESS_ASSIGNED_VDR assigned VDR state 206
  • SESS_COI_PROV_REQ VDR provisioning request state 208
  • VDR active state 210 SESS_COI_ACTIVE
  • the null session state 202 represents a VDR in an available pool and lacking any routing or association with a VPN IP address.
  • VDRs have a service key loaded and an associated IP address.
  • the VDR request state 204 or starting state, generally has no routing, and is not associated with a VPN IP address. Rather, in mis starting state the VDR broker 112 can create or start a container and start a Stealth service key mode, allowing the VDR to be allocated from the available pool.
  • the assigned VDR state 206 still has no routing, but has a service key loaded and includes IP addresses.
  • the assigned VDR state 206 is associated with a VPN IP address, corresponding that VDR with a particular secure connection to a mobile application.
  • VDR in the assigned VDR state still has no community of interest material (keys, etc.) assigned, so communication by the mobile device within the Stealth network 130 is not yet enabled.
  • the VDR broker 112 In the VDR active state 210, the VDR broker 112 has assigned the VDR 114 with routing information, an associated VPN IP address, and community of interest material. Furthermore, the VDR broker 112 has opened a license tunnel, allowing for validation of the COI material within the Stealth network 130.
  • the event manager 118 of the example embodiments described above tracks state transitions among the various states 202-210, which may transition based on actions taken by the VDR broker 112. Various actions may be performed.
  • actions can include:
  • a session creation action 220 (ACT_CREATE SESSION), which creates a session entry and assigns a session ID;
  • ACT_REQ_VDR a request VDR action 222
  • the request VDR action 222 triggers a VPN_CONNIiCTION_START event passing a usemame and IP address of the mobile endpoint from the VPN server 104 to the VDR broker 112.
  • VDR assignment action 224 ACT_VDR_ASSIGN_COMPLETE
  • VDR provisioning action 226 (ACT_PROV_VDR.) > which sends a provision request to the VDR manager;
  • VDR provisioning verification action 228 (ACT_PROV_COMPLETE), which resets a state of the VDR to active, as noted below; and a VDR discarding action 230 (ACT_VDR_DISCARD), which issues a VDR discard request to the VDR manager; and
  • VDR_ASSIGN_RSP vdr assignment response
  • ACT_VDR_ASS1GN_C0MPLETE VDR assignment action 224
  • An authentication completion indication (AUTH_COMPLETE_IND), corresponding to a message from the authentication manager that a Stealth user has been authenticated by the authentication server 134, includes a username, gateway, and COI response from the authentication server, and triggers the VDR provisioning action 226, which in turn transitions the VDR to a VDR provisioning request state 208.
  • a VDR provisioning verification action 228 will transition the VDR to a VDR active state 210, upon occurrence of a verification message (VDR_PROV_COMPLETE) from the VDR manager.
  • connection stop message (VPN_CONNECTON_STOP) received from the VPN server 104 indicating that a VPN tunnel has closed will cause transition to return to a VDR provisioning action 226, triggering attempts to re-provision the VDR with the associated mobile device upon reconnection of the VPN tunnel.
  • a particular arrangement 300 is shown, allowing a mobile device to connect to a plurality of different communities of interest, according to an example embodiment.
  • the arrangement 300 illustrates connectivity within a broker host 302, which generally represents a computing system hosting the VDR broker 112 of Figure 1.
  • a mobile device 102 can connect to a VPN gateway 304 (e.g., corresponding to VPN server 104 of Figure 1) via a public network 310.
  • the connection between the mobile device 102 and VPN gateway 304 can be a tunneled, IPsec- based secure connection. In the embodiment shown, this connection is shown as accessible to the mobile device via address 10.99.95.1/24 (by way of example only).
  • the VPN Gateway communicates with the broker host 302 via a network 320, at which it exposes a second IP address by which it communicates. In the example shown, the VPN gateway 304 is accessible using IP address 10.98.0.4.
  • a plurality of VDRs are established by the VDR broker (not shown here, but as discussed above).
  • the mobile device 102 can communicate separately with two different VDRs, given IP addresses 10.97.0.1 and 10.97.0.2. Accordingly, a first application at the mobile device 102 may have a first secure connection to a first VDR 314a (accessing at 10.97.0.1), while a second application at the mobile device 102 may have a second, separate secure connection to a second VDR 314b (accessing at 10.97.0.2).
  • Such different VDRs may be assigned different COI credentials, allowing the first VDR 314a to connect to a first set of endpoints within a first community of interest 312a (shown as “Blue COI”), while a second VDR 314b can connect to a second set of endpoints within a second community of interest 312b (shown as "Red COI").
  • an authentication server 334 can be presented either at network 320 or network 330, and is accessible within the local subnet to pass COI credentials to the VDRs based on a request received from the VDR broker at the broker host 302.
  • a licensing tunnel can be established to a licensing gateway 336 (analogous to licensing server 136) at network 320 or network 330 as well, and can connect to a licensing VDR 333 via an address within subnets facing either network 320 or 330 (subnets 10.97.0.x or 10.1.1.x) at a known address to allow for establishing and monitoring a licensing connection at the broker host 302.
  • FIG. 4 a flowchart of a method 400 for enabling communication between a mobile device and one or more secure endpoints included within a secured network is shown.
  • the method 400 can be performed within a network such as network [00 , to initialize and perform communications between a mobile device (e.g., mobile device 102) and an endpoint within a secure network (e.g., Stealth network endpoints 132a-b within an allocated COI).
  • the method 400 is performed based on selecting an appropriate VPN client and connection that is configured for connection to a VPN server affiliated with a secured network, such as VPN server 104 associated with a Stealth network 130 of Figure 1.
  • the method 400 includes initiating a VPN connection from the mobile device (step 402). This can include enabling the VPN client, and prompting a user of the VPN client to connect to the VPN server, for example using a username/password or other authentication credentials.
  • the mobile device Upon establishment of the VPN connection the mobile device will have a working network path to the VPN server and an associated VDR broker, but cannot yet access a Stealth-based intranet or associated services.
  • initiating a VPN connection from the mobile device can include starting a Stealth-specific mobile application (step 404) and initializing a Stealth connection at the mobile device.
  • Such embodiments which may be required by some operating systems that do not enable IPsec -based connections natively, may require additional connection parameters (e.g., a passphrase or other secure communication credentials) which allow the user to open an SSL connection between the VPN server and the VDR broker. The user can then enter his or her username and password information to allow for a logon connection to the VDR broker.
  • the method 400 further includes the VDR broker interacting with an authentication server (e.g., authentication server 134 of Figure 1A, or authentication server 334 of Figure 3) to pass the user's credentials to the authentication server for authentication (step 406).
  • the VDR broker transmits a tuples request to the authentication server and obtains a public certificate from the authentication server.
  • the authentication manager e.g., authentication manager 113 of Figure IB
  • the wrapping key obtained from the VDR is then returned to the authentication server, which (upon positive authentication) returns the response to the tuples request including COI information (including COI keys) wrapped with the VDR's wrapping key.
  • the method 400 also includes the VDR broker starting the VDR associated with the COI information (step 408).
  • the VDR broker than passes the COI key IDs, appliance IP addresses, key status, and other connection information to the VDR.
  • the mobile application further includes, in some example embodiments, the mobile application receiving an answering response based on the authentication request transmitted by the mobile device (step 410), indicating to the mobile device the success or failure of establishing a secure connection to the desired Stealth-enabled network (specifically, the assigned COIs within that network).
  • FIGS 5A-5B, 6A-6B, and 7-8 various messaging and events are described illustrating example connection and disconnection sequences occurring between a mobile device and a Stealth-enabled network (by way of a mobile gateway and associated VDR broker).
  • Figures 5A-5B illustrate an event sequence 500 occurring at a mobile gateway to establish a VDR used for communication between a mobile device and one or more secure endpoints included within a secured network, according to an example embodiment.
  • operational event sequences occur among an event manager, an authentication manager, a VPN manager, and a VDR manager, examples of which are discussed above in connection with Figure IB.
  • a VPN manager indicates an initialized VPN connection to a mobile device.
  • the event manager e.g., event manager 118
  • the event manager then sends a VDR request to the VDR manager, and indicates a state should be set at SESS_REQ_VDR (e.g., VDR request state 204), indicating to request a VDR to be allocated.
  • the event manager passes a message to VDR manager (e.g., VDR manager 116), which shuts down a VDR if a maximum number of VDRs has been reached, or otherwise allocates a new VDR.
  • the event manager receives confirmation of the allocated VDR, and updates a table entry in VDR table 131 with a requestID, VPN IP, resultcode, and result text.
  • the event manager also logs the allocation of the VDR.
  • the event manager returns a message to the VPN manager.
  • the authentication manager receives a login request from a mobile application, and event manager transmits a VDR assignment to the VDR manager.
  • the VDR manager assigns a VDR and returns an assigned VDR, routing information, and a wrapping key.
  • the event manager updates a table to indicate a state of the VDR as an assigned VDR state 206 (SESS_ASSIGNED_VDR) and stores a stealth user name, wrapping key, requestID, and VPN IP in the VDR table 131.
  • the event manager then provides to the authentication manager a message, causing the authentication manager to transmit a tuples request to the authentication server (e.g., authentication server 134 or 334 of Figures 1A, 3).
  • the authentication server e.g., authentication server 134 or 334 of Figures 1A, 3
  • the tuples request can include, for example, a username, password, and public key, and a response to the tuples request can be received that includes the request ID, VPN IP address, sessionID, and a tuples XML file including COI information wrapped with the wrapping key of the VDR.
  • the event manager the updates a state of the VDR (to the VDR provisioning request state 208, SESS_COI_PROV_REQ), and logs the information retrieved.
  • the event manager passes the received information to the VDR manager which provisions the VDR instance with the various information (COI information in the form of the tuples XML file, as well as username information and session information).
  • the VDR manager starts the Stealth service, and the event manager updates the state of that VDR to SESS_COI_ACTIVE (VDR active state 210).
  • the authentication manager then passes a status of authentication back to the mobile device, confirming successful authentication.
  • FIGS 6A-6B illustrate a sequence of communications 600 among devices in establishing communications between a mobile device and one or more secure endpoints within a secured network, according to an example embodiment.
  • the sequence of communication 600 can occur among a mobile device (e.g., mobile device 102), a VPN appliance (e.g., VPN server 104), a VDR broker (e.g., VDR broker 112 at mobile gateway 106), a VDR (e.g., VDR 114), and an authentication server (e.g., authentication server 134).
  • a mobile device e.g., mobile device 102
  • VPN appliance e.g., VPN server 104
  • VDR broker e.g., VDR broker 112 at mobile gateway 106
  • VDR e.g., VDR 114
  • an authentication server e.g., authentication server 134
  • a mobile device starts a secure application and provides a certificate, username, and password to the VPN appliance.
  • the VPN appliance authenticates the mobile device and establishes a secure (e.g., IPsec-based tunneled) connection between the mobile device and VPN appliance.
  • the VPN appliance transmits a session ID and VPN IP address to the VDR broker, which allocates a VDR and sends an acknowledgement back to the VPN appliance.
  • the mobile device then transmits a login request to the VDR broker, which obtains a wrapping key from an allocated VDR and builds a tuples request.
  • the VDR broker transmits the tuples request to the authentication server, which includes the wrapping key and the user's login credentials.
  • the authentication server authenticates the user based on the login credentials, and returns that user's COI keys wrapped with the VDR wrapping key to the VDR broker as a tuples XML response.
  • the VDR broker sends a Stealth configuration to the VDR, which opens a license tunnel to a home appliance, and returns status information to the VDR broker.
  • the VDR broker in turn optionally returns the status information to the mobile device for confirmation.
  • the established tunnel can be closed by the mobile device transmitting a tunnel close message to the VPN appliance, which stops the VPN connection and transmits a stop message, alongside a session ID and the VPN IP address, to the VDR broker.
  • the broker updates and deallocates the VDR, and confirms with the VPN appliance.
  • a VDR shutdown messages is transmitted to the VDR associated with the VPN IP address and session ID, and the VDR returns a shutdown confirmation message upon shutdown to the VDR broker.
  • Figure 7 illustrate a sequence of communications 700 among devices in performing a logoff operation for a first user, and establishing communications between a mobile device and one or more secure endpoints within a secured network for a second user, according to an example embodiment.
  • the sequence of communications 700 as shown generally occurs among the same devices, or types of devices, as discussed above in connection with Figures 6A-6B.
  • the mobile device transmits a logoff message associated with a first user and session (shown as User X and Session ID).
  • the VDR broker transmits a stealth service key state message to the VDR, which returns an acknowledgement and the service key state to the VDR broker.
  • a subsequent login message from the mobile device, associated with a different user (User Y) is received at the VDR broker, which obtains the wrapping key from the VDR, and builds a tuples request.
  • the VDR broker retrieves COI information associated with the user (in this case User Y) retrieved from the authentication server wrapped in the wrapping key.
  • the VDR broker then configures the VDR, which opens a license tunnel and initiates communication.
  • the VDR broker transmits an updated status indicating successful connection to the mobile device, which optionally displays status information indicating successful connection.
  • FIG. 8 illustrates a sequence of communications 800 among devices in performing a connection process in which a VPN error occurs, according to an example embodiment.
  • the VPN appliance upon occurrence of a VPN error, the VPN appliance will close a VPN tunnel and indicate to the VDR broker that the tunnel has closed.
  • the VDR broker will close the Stealth connection and transmit a message to the VDR associated with the mobile device to close all tunnels.
  • the VDR will return an acknowledgement to the VDR broker, which disables routing, shuts down the VDR, and updates its state tables.
  • the mobile device which has an application status connection, will identify the failed VPN connection and display an indication of failed connectivity.
  • Figure 9 illustrates a sequence of communications among devices in performing a connection process in which a Stealth tunnel error occurs and is closed, according to an example embodiment.
  • the VDR transmits a notification to the VDR broker, which updates the VDR table 131, setting a status to offline.
  • the mobile device will request an application status from the VDR broker, and, upon finding that a status of the VDR is "offline", will turn off Stealth and turn it back on, attempting reconnection.
  • the VDR broker will try to reopen the license tunnel, and, upon successful reopening of the license tunnel from the VDR, the VDR broker will update status and return that status to the mobile device for display.
  • FIG. 10 an arrangement [000 of the network of Figure 1 according to a further example embodiment providing high-availability connection for mobile devices to a Stealth-enabled network is shown.
  • the arrangement [000 ensures availability of a VDR by establishing redundant mobile gateways.
  • three client device connections [002a-c are shown, connecting to two different mobile gateways [006 (via VPN appliances, not shown).
  • VDR instances 1014 are redundant across the gateways and pooled between switches 1020, allowing for shared usage of VDRs across the mobile gateways.
  • the client device connections [002a-c can be made to either mobile gateway, with an L2 switch cluster communication module 1015 managing communication therebetween.
  • cluster nodes 1022a-c are provided in which additional VDR instances are provided at cluster nodes, and are connected in a redundant, star-configuration to the Stealth-enabled network.
  • FIG. 11-13 example details regarding computing systems in which aspects of the present disclosure can be implemented are provided. Such computing systems represent optional emulated environments in which the methods and systems of the present disclosure can be implemented, for example using the hardware systems disclosed above in connection with Figures 1, 3, and 10.
  • FIG 11 illustrates a computer system 1 [00 adapted according to certain embodiments of the gateway computing device, server and/or the user interface device.
  • the central processing unit (“CPU") 1102 is coupled to the system bus 1104.
  • the CPU 1102 may be a general purpose CPU or microprocessor, graphics processing unit (“GPU”), and/or microcontroller.
  • the present embodiments are not restricted by the architecture of the CPU 1102 so long as the CPU 1102, whether directly or indirectly, supports the operations as described herein.
  • the CPU 1102 may execute the various logical instructions according to the present embodiments.
  • the computer system 1 [00 also may include random access memory (RAM) 1108, which may be synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), or the like.
  • RAM random access memory
  • the computer system 1 [00 may utilize RAM 1108 to store the various data structures used by a software application.
  • the computer system 1 [00 may also include read only memory (ROM) 1106 which may be PROM, EPROM, EEPROM, optical storage, or the like.
  • ROM read only memory
  • the ROM may store configuration information for booting the computer system 1 [00.
  • the RAM 1108 and the ROM 1106 hold user and system data, and both the RAM 1108 and the ROM 1106 may be randomly accessed.
  • the computer system 1 [00 may also include an input/output (I/O) adapter 1110, a communications adapter 1114, a user interface adapter 1116, and a display adapter 1122.
  • the I/O adapter 1110 and/or the user interface adapter 1116 may, in certain embodiments, enable a user to interact with the computer system 1 [00.
  • the display adapter 1122 may display a graphical user interface (GUI) associated with a software or web-based application on a display device 1124, such as a monitor or touch screen.
  • GUI graphical user interface
  • the I/O adapter 1110 may couple one or more storage devices 1112, such as one or more of a hard drive, a solid state storage device, a flash drive, a compact disc (CD) drive, a floppy disk drive, and a tape drive, to the computer system 1 [00.
  • the storage device 1112 may be a separate server coupled to the computer system 1 [00 through a network connection to the I/O adapter 1110.
  • the communications adapter 1114 may be adapted to couple the computer system 1 [00 to the network 1208, which may be one or more of a LAN, WAN, and/or the Internet
  • the communications adapter 1114 may also be adapted to couple the computer system 1 [00 to other networks such as a global positioning system (GPS) or a Bluetooth network.
  • the user interface adapter 1116 couples user input devices, such as a keyboard 1120, a pointing device 1118, and/or a touch screen (not shown) to the computer system 1 [00.
  • the keyboard 1120 may be an onscreen keyboard displayed on a touch panel. Additional devices (not shown) such as a camera, microphone, video camera, accelerometer, compass, and or gyroscope may be coupled to the user interface adapter 1116.
  • the display adapter 1122 may be driven by the CPU 1102 to control the display on the display device 1124.
  • Any of the devices 1102-1122 may be physical and/or logical.
  • the applications of the present disclosure are not limited to the architecture of computer system 1 [00. Rather the computer system 1 [00 is provided as an example of one type of computing device that may be adapted to perform the functions of a server and/or a user interface / client device.
  • any suitable processor-based device may be utilized including, without limitation, personal data assistants (PDAs), tablet computers, smartphones, computer game consoles, and multi-processor servers.
  • the systems and methods of the present disclosure may be implemented on application specific integrated circuits (ASIC), very large scale integrated (VLSI) circuits, or other circuitry.
  • ASIC application specific integrated circuits
  • VLSI very large scale integrated circuits
  • persons of ordinary skill in the art may utilize any number of suitable structures capable of executing logical operations according to the described embodiments.
  • the computer system 1 [00 may be virtualized for access
  • FIG. 12 is a block diagram illustrating a server hosting an emulated software environment for virtualization according to one embodiment of the disclosure.
  • An operating system 1202 executing on a server includes drivers for accessing hardware components, such as a networking layer 1204 for accessing the communications adapter 1114.
  • the operating system 1202 may be, for example, Linux.
  • An emulated environment 1209 in the operating system 1202 executes a program 1210, such as CPCommOS.
  • the program 1210 accesses the networking layer 1204 of the operating system 1202 through a non-emulated interface 1206, such as XNIOP.
  • the non-emulated interface 1206 translates requests from the program 1210 executing in the emulated environment 1209 for the networking layer 1204 of the operating system 1202.
  • FIG. 13 is a block diagram illustrating a server hosting an emulated hardware environment according to one embodiment of the disclosure.
  • Users 1252, 1254, 1256 may access the hardware 1260 through a hypervisor 1258.
  • the hypervisor 1258 may be integrated with the hardware 1260 to provide virtualization of the hardware 1260 without an operating system, such as in the configuration illustrated in Figure 11.
  • the hypervisor 1258 may provide access to the hardware 1260, including the CPU 1102 and the communications adapter 1114.
  • Computer-readable media includes physical computer storage media.
  • a storage medium may be any available medium that can be accessed by a computer.
  • such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.
  • Disk and disc includes compact discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy disks and Blu-ray discs. Generally, disks reproduce data magnetically, and discs reproduce data optically. Combinations of the above should also be included within the scope of computer-readable media.
  • Computer storage media generally includes at least some tangible, non-transitory media and can, in some embodiments, exclude transitory wired or wireless signals.
  • Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media.
  • modulated data signal may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal.
  • communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as Wi-Fi, acoustic, radio frequency (RF), infrared, and other wireless media.
  • the term computer readable media as used herein may include computer storage media, but generally excludes entirely transitory embodiments of communication media, such as modulated data signals.
  • instructions and/or data may be provided as signals on transmission media included in a communication apparatus.
  • a communication apparatus may include a transceiver having signals indicative of instructions and data. The instructions and data are configured to cause one or more processors to implement the functions outlined in the claims.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne des procédés et des systèmes de communication avec des points d'extrémité sécurisés inclus dans un réseau sécurisé à partir d'un dispositif mobile externe au réseau sécurisé. Le procédé consiste à initier une connexion sécurisée basée sur VPN à un appareil VPN (104), et à initialiser un service furtif sur le dispositif mobile (102). Le procédé consiste en outre à transmettre des informations de justificatif d'identité d'utilisateur du dispositif mobile à un courtier de relais de dispositif virtuel (VDR) (112) par l'intermédiaire de l'appareil VPN, et à recevoir des informations d'état à partir du courtier VDR identifiant un VDR (114) associé au dispositif mobile, et à fournir un état connecté. Le procédé consiste également à communiquer avec un ou plusieurs points d'extrémité sécurisés (132) dans le réseau sécurisé (130) par l'intermédiaire d'une connexion VPN au VDR par l'intermédiaire de l'appareil VPN et par l'intermédiaire du VDR au ou aux points d'extrémité sécurisés dans une communauté d'intérêt sur la base des informations de justificatif d'identité d'utilisateur transmises au courtier VDR.
PCT/US2015/038239 2014-06-30 2015-06-29 Communications de réseau sécurisé dans un dispositif mobile sur ipsec Ceased WO2016003860A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462018956P 2014-06-30 2014-06-30
US62/018,956 2014-06-30
US14/753,146 US9794225B2 (en) 2005-01-31 2015-06-29 Secure network communications in a mobile device over IPsec
US14/753,146 2015-06-29

Publications (1)

Publication Number Publication Date
WO2016003860A1 true WO2016003860A1 (fr) 2016-01-07

Family

ID=55019864

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/038239 Ceased WO2016003860A1 (fr) 2014-06-30 2015-06-29 Communications de réseau sécurisé dans un dispositif mobile sur ipsec

Country Status (1)

Country Link
WO (1) WO2016003860A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130133043A1 (en) * 2011-04-27 2013-05-23 International Business Machines Corporation Authentication in virtual private networks
US20130291086A1 (en) * 2011-02-11 2013-10-31 Mocana Corporation Ensuring network connection security between a wrapped app and a remote server
US20140123268A1 (en) * 2012-10-31 2014-05-01 Unisys Corporation Secure connection for a remote device through a mobile application

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130291086A1 (en) * 2011-02-11 2013-10-31 Mocana Corporation Ensuring network connection security between a wrapped app and a remote server
US20130133043A1 (en) * 2011-04-27 2013-05-23 International Business Machines Corporation Authentication in virtual private networks
US20140123268A1 (en) * 2012-10-31 2014-05-01 Unisys Corporation Secure connection for a remote device through a mobile application

Similar Documents

Publication Publication Date Title
US9912663B2 (en) Enabling secure network mobile device communications
US9571455B2 (en) Remote credential management for hybrid clouds with enterprise networks
AU2020200907B2 (en) Automated provisioning of virtual machines
US10454931B2 (en) Secure remote access for secured enterprise communications
US10749971B2 (en) Virtual private network gateway management
EP2873214B1 (fr) Passerelles virtuelles permettant d'isoler des machines virtuelles
US20150381567A1 (en) Cleartext gateway for secure enterprise communications
US10417428B2 (en) Methods and systems for providing and controlling cryptographic secure communications terminal providing a remote desktop accessible in secured and unsecured environments
JP2019526843A (ja) ホストされたアプリケーションへの動的アクセス
CN115033190A (zh) 基于位置的装置可用性
JP2010062738A (ja) ネットワーク設定プログラム，ネットワーク設定方法及びネットワーク設定装置
US20210294891A1 (en) Virtual relay device for providing a secure connection to a remote device
US20160344547A9 (en) Secure connection for a remote device through a virtual relay device
US10735387B2 (en) Secured network bridge
JP7682997B2 (ja) クラウドシェルのインスタンスにわたってデータを永続化するための技法
JP2021535521A (ja) 仮想デスクトップでのローカルマップアカウント
US9794225B2 (en) Secure network communications in a mobile device over IPsec
US10601802B2 (en) Method for distributed application segmentation through authorization
JP2022516290A (ja) 汚染された接続エージェントの追跡
WO2016003885A1 (fr) Passerelle de texte en clair pour des communications d'entreprise sécurisées
WO2016003860A1 (fr) Communications de réseau sécurisé dans un dispositif mobile sur ipsec
WO2016003566A1 (fr) Intégration sécurisée de nuages hybrides avec des réseaux d'entreprise
JP2025176038A (ja) 高度に利用可能なフローのための通信チャネル状態情報の同期
CN116746136A (zh) 同步通信信道状态信息以实现高流量可用性

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: 15741682

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15741682

Country of ref document: EP

Kind code of ref document: A1