How does the Linchpin Mobile Gateway work?

The Linchpin Mobile Gateway behaves like a proxy, allowing authorized mobile devices to access systems (such as Confluence or Linchpin) behind a firewall. This is made possible by a Websocket connection, which is established and maintained by the system behind the firewall to the Linchpin Mobile Gateway. It does not matter whether the Linchpin Mobile Gateway is hosted by //SEIBERT/MEDIA in the cloud, or in your own infrastructure - both options use the same technology.

With Linchpin Mobile, the Websocket connection to the gateway is established by the Linchpin Mobile Confluence app. After successfully connecting Confluence to the Gateway, mobile devices can also use the Linchpin Mobile app to establish a Websocket connection to the Gateway. From this point on, mobile devices can communicate with a Confluence instance behind a firewall via the Linchpin Mobile Gateway based on a pub/sub pattern.

How do we secure your information?

To secure your data, we rely on an end-to-end encrypted Websocket connection. All data is encrypted on the employee's mobile device before it is forwarded via the Linchpin Mobile Gateway. The Linchpin Mobile app installed in your Confluence instance can decrypt and process the data.

This means that your data is not only inaccessible to //SEIBERT/MEDIA, but also to third parties. And with our Linchpin Mobile Gateway on-site option, you have control of the gateway itself for even more security.

 

eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6Ii8vU0VJQkVSVC9NRURJQSBFbXBsb3llZSIsIm91dHB1dFR5cGUiOiJibG9jayIsImxhc3RNb2RpZmllck5hbWUiOiJTZWliZXJ0IE1lZGlhIGVtcGxveWVlIiwibGFuZ3VhZ2UiOiJlbiIsImRpYWdyYW1EaXNwbGF5TmFtZSI6IiIsInNGaWxlSWQiOiIiLCJhdHRJZCI6IjEyNDg4MzM0IiwiZGlhZ3JhbU5hbWUiOiJQcm9ibGVtV2l0aE1vYmlsZSIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJMaW5jaHBpbiBNb2JpbGUgR2F0ZXdheSAtIFNlY3VyaXR5IENvbmNlcHQiLCJ0YnN0eWxlIjoiaGlkZGVuIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjpmYWxzZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoxMjQ4ODMzNiwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MTI0ODgzMzYsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEzLCJtYWNyb0lkIjoiMTA5ZTQ2NjQtMTU0YS00YTVmLWJkZjItYjFjNWU0OTAxNWFjIiwicHJldmlld05hbWUiOiJQcm9ibGVtV2l0aE1vYmlsZS5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoiOTgxIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNTE1NTc4MzA5MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==

In general, employees can not access a Linchpin intranet that sits behind a firewall using a mobile app from outside the corporate network (i.e. from home). Traditionally, there are two workarounds:

1. Operate Linchpin in a DMZ (demilitarized zone), accessible from the internet.
2. Grant every employee VPN access.

Both approaches have their own problems. Allowing free access from the internet greatly increases the attack risks on the LINCHPIN application and the server. Providing VPN access to each employee is a major administrative burden for the company's IT services, and the workforce is faced with yet another hurdle when it comes to using applications which should be quickly and easily available externally.

The Linchpin Mobile Gateway service, offered by //SEIBERT/MEDIA, provides a third alternative.

A Connector Plugin, specifically developed for this purpose, is installed in Linchpin, and initiates an outgoing connection to the Gateway Service. At the Gateway Service, this connection is converted into a bi-directional WebSocket connection and is kept permanently open. This allows the Gateway Service and the Linchpin Mobile Connector Plugin to exchange data at any time, without requiring the Gateway Service (or any third party from the internet) to actively establish an incoming connection to Linchpin. No incoming connections to the firewall are needed.

When the bi-directional WebSocket connection is established between Connector Plugin and Gateway Service, authorized apps can send requests to the Gateway Service, which will forward them to the Connector Plugin using the existing connection.

The same basic requirements are implemented as for all IT systems at //SEIBERT/MEDIA, including:

• Up-to-date Linux operating systems (currently Ubuntu 18.04 LTS) are used, with automatic security updates.
• A firewall blocks access to internal services from the internet. Maintenance, backup, monitoring are only done via the internal network.
• Clearly defined access rights for administrators are on a person-to-person basis, there are no general administration accounts.
• Detailed automatic logging of all activities in the system is performed (audit log and reporting).
• Hosting is in the ISO 27001 and ISO 9001 certified data center in Frankfurt am Main with a German provider in accordance with the German Data Protection Act (BDSG)

However, the most important security measure is not on the operational side, but in the concept:

This concept can be compared to a transparent tunnel, which does not need to know anything about the content that is being transferred. The following section explains in detail how this architecture has been implemented.

Phase 1: Connection is established between the Connector Plugin and Gateway Service

After the Connector Plugin has been installed in LINCHPIN, it logs into the Gateway Service. A simple HTTPS request from the Connector Plugin is sent to the Gateway Service:

The Gateway Service now generates random access data for the plugin, an instance_id as the username, and an instance_password, each containing 128 random bits. The required entropy is ensured via haveged. This access data is sent as a response to the Connector Plugin and stored there. The Gateway Service only stores a PBKDF2 hash (100,000 iterations) of the password. The following table provides an overview of the stored information at this time:

In the second step, the Linchpin Mobile Plugin will again send an HTTPS request to the gateway service. Instead of a response from the Gateway Service the connection is upgraded to a WebSocket connection. This connection is still encrypted using HTTPS, but it supports bi-directional data exchange and is held for an indefinite time. An MQTT session is now established within the WebSocket connection, authenticated via the previously exchanged instance_id and instance_password.

Phase 2: Device registration

To allow a user to use the Gateway Service, a device must first be registered. To do this, the Connector Plugin authenticates itself with the Gateway Service's REST API using its instance_id and instance_password and requests to register a device. The Gateway Service generates a device_id, which is used to authorize the device on an ongoing basis to use the connection between the Gateway Service and the Connector Plugin, and a device_setup_key. This device_setup_key is not permanently stored by the Connector Plugin, but is integrated into a QR code. The Connector Plugin also generates a device_setup_secret_key that is stored both in Linchpin and in the QR code.

Here is an updated overview of the data stored at this time:

The QR code can now be printed or displayed to the user on screen. The app reads the device_setup_key and device_setup_secret_key from the QR code using its camera. The app then contacts the Gateway Service's REST API and exchanges its device_setup_key for a device_id and a device_password, generated randomly by the Gateway Service.

This results in the following stored data:

The device_setup_key is invalidated at this time as it is no longer relevant.

Phase 3: Communication requests from the app to the Connector Plugin

From this point on, the app can communicate with the Connector Plugin. The first request is used to create a new device_secret_key because the current device_setup_secret_key is still visible in the QR code and should not be permanently valid (this means that a QR code can be simply discarded). The app sends the following request to the Gateway Service:

Sender: device_id (authenticated with device_password)
Content: AES("Request for device_secret_key", device_setup_secret_key)

The content of the request is encrypted symmetrically by AES and can not be read by the Gateway Service (since it does not know the device_setup_secret_key). However, the Gateway Service can compare the device_id to the hash of an instance_id and forward the request to the linked instance_id. Requests for the Linchpin Mobile Plugin will now use this connection.

The Linchpin Mobile Plugin receives the message via the WebSocket connection, and uses the device_id with the device_setup_secret_key and thus decrypt the content. Now the Linchpin Mobile Plugin can generate a device_secret_key, encrypt its reply with the device_setup_secret_key and send it back to the app using the same connection. Once the app receives the device_secret_key, the device_setup_secret_key is discarded. This means that all data contained in the QR code is invalidated and can not be reused by unauthorized third parties.

All subsequent requests from the app follow the same process: The device_id is used to assign queries in the Gateway Service to an instance_id and a WebSocket connection. The complete content of the request is encrypted with the device_secret_key and thus not readable by the Gateway Service. The same applies to responses from the Linchpin Mobile Plugin.

By linking the device_id to a Confluence user's account, the Linchpin Mobile Plugin can provide content tailored to the user and their permissions.

Data retention

In conclusion, this is what data is accessible by each service:

Name	Use	Device (App)	QR code	Gateway Service	Linchpin Mobile Plugin
instance_id	Identifies an installed Linchpin Mobile Plugin
instance_password	Authenticates an installed Linchpin Mobile Plugin			*
device_id	Identifies access information in the Linchpin Mobile App
device_password	Authenticates an installed Linchpin Mobile App			*
device_setup_key	Temporary token used once to negotiate permanent access data between the app and the Gateway Service			*
device_setup_secret_key	Temporary key used once to negotiate a permanent key between the app and the Linchpin Mobile Plugin	*	*		*
device_secret_key	Permanent key used for end-to-end encryption between the app and the Linchpin Mobile Plugin
Confluence URL
User names
Passwords
Content

 * = only initially saved, subsequently rotated

 = only during transmission, data is not saved.

* = only during transmission, a hash of the data is saved.