On this page:

Security Concept

Summary

All connections are encrypted according to current standards (HTTPS).

As a rule, no firewall modifications on the client side are required. Your Linchpin instance only needs to be able to establish HTTPS connections to the internet.

Linchpin Mobile app users do not necessarily need to have an account in your user directory (Active Directory or similar). This saves on licensing costs.

By dispensing with classic password authentication, associated support costs for forgotten passwords and other risks are eliminated.

End-to-end encryption between the mobile app and Linchpin does not allow either Seibert Group GmbH or a potential attacker to steal your data from your Linchpin instance.

At Seibert Group GmbH, no data is stored that could allow conclusions to be drawn about your identity, user information or any Linchpin Mobile customer data.

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 Group GmbH 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 Group GmbH, 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.

The problem

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 Group GmbH, provides a third alternative.

The solution

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.

Security and privacy

The same basic requirements are implemented as for all IT systems at Seibert Group GmbH, 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.

Implementation in detail

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:

App Gateway Service Connector Plugin QR Code
instance_id

pbkdf2(instance_password)

 instance_id

instance_password

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:

App Gateway Service Connector Plugin QR Code
instance_id

pbkdf2(instance_password)

device_id

sha256(device_setup_key)

 instance_id

device_id (linked to the Confluence user account)

device_setup_secret_key

 device_setup_key

device_setup_secret_key

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:

App Gateway Service Connector Plugin QR Code
device_id

device_password

 instance_id

pbkdf2(instance_password)

device_id

pbkdf2(device_password)

 instance_id

device_id (linked to the Confluence user account)

device_setup_secret_key

 device_setup_key

device_setup_secret_key

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 (Haken) (Fehler) (Haken) (Haken)
instance_password Authenticates an installed Linchpin Mobile Plugin (Fehler) (Fehler) (Warnung)* (Haken)
device_id Identifies access information in the Linchpin Mobile App (Haken) (Fehler) (Haken) (Haken)
device_password Authenticates an installed Linchpin Mobile App (Haken) (Fehler) (Warnung)* (Fehler)
device_setup_key Temporary token used once to negotiate permanent access data between the app and the Gateway Service (Warnung) (Haken) (Warnung)* (Warnung)
device_setup_secret_key Temporary key used once to negotiate a permanent key between the app and the Linchpin Mobile Plugin (Haken)* (Haken)* (Fehler) (Haken)*
device_secret_key Permanent key used for end-to-end encryption between the app and the Linchpin Mobile Plugin (Haken) (Fehler) (Fehler) (Haken)
Confluence URL (Fehler) (Fehler) (Fehler) (Haken)
User names (Fehler) (Fehler) (Fehler) (Haken)
Passwords (Fehler) (Fehler) (Fehler) (Fehler)
Content (Haken) (Fehler) (Fehler) (Haken)

(Haken) * = only initially saved, subsequently rotated

(Warnung) = only during transmission, data is not saved.

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

Link to this page: http://seibert.biz/linchpinmobilesecurity