GPSdancer is a network process, and only works when the involved computers can communicate with each other over the internet. The internet is a nasty environment, that is systematically scanned by tens of thousands of malicious scripts, annoying advertisement robots and similar undesired intruders. This very website GPSdancer.org has been hacked twice by Chinese hackers. On both occasions, some data was lost - in sspite of backups, etc. - while the restoration of the webserver from scratch always requires a substantial effort. The lesson learned is that we must take every possible precaution to protect the running GPSdancer processes. This article summarizes the most important measures.

Firewalls

The observation data of the CORS stations needs to travel to its associated GPSdancer instance, somewhere on the internet. This connection is not different from today's communication between a CORS station and e.g. a regional data centre or analysis centre, but still needs to be secure. However, the involved IP addresses are permanent, so that both end of the connection can use a white-list firewall approach: only known (trusted) IP addresses can communicate with the local computer. This is the most secure way of network communication, but also the least flexible.

The GPSdancer processes themselves need to communicate with each other in the square dance exchange process. Thanks to the overlayed point to point communication mechanism and broadcast mechanism, the processes do not need any additional network connections than those for the square dance algorithm. A GPSdancer process will therefore have around $$\log_2{N}$$ independent network connections  The set of GPSdancer processes changes dynamically whenever new CORS stations join or existing CORS stations leave the solution network. This means that any of the $$N$$ other processes must be allowed to connect to our local process.

This last condition means that a GPSdancer process that runs on the public internet is inherently insecure. It cannot use a white-list firewall strategy, because each change in the network would require all GPSdancer processes to update their firewall rules, which is impractical. An intermediate solution is to reserve IP addresses within a certain range, and allow the full range of addresses to connect to our local server. This is one reason why it makes sense to run GPSdancer in the cloud, so that the range of IP addresses of the cloud provider can be the only tolerated range of remote computers to connect with.

Private accounts

Even when multiple GPSdancer instances would run on a single computer, each CORS station will have an individual user account with public/private key access. This allows upload of the observation data, and download of the CORS products. If each CORS process runs its own GPSdancer process, it is clear that the CORS data is invisible to other CORS processes and their operators (...in the same way that you as a CORS operator cannot see the data or products of other operators). However, if multiple GPSdancer instances share a single computer, it would be inefficient if they all run their own software instance, especially in use of memory (...the global matrix partition occupies several Gigabytes...). In that case, a single GPSdancer process needs read/write access to all individual CORS accounts on that computer. This is achieved by creating a (unix-style) user group for each CORS station with only two users in the group: the CORS user itself, and a common user called GPSdancer (...not root!). The GPSdancer also has its own account, to which no other user has read/write access. In this account, the GPSdancer process is running, reading inputs and writing outputs to all CORS accounts as needed. This GPSdancer user communicates with the other computers in the network,as described in the article on the distributed solution process.

Non-disclosure agreement (NDA)

It may be difficult to convince CORS operators that the GPSdancer system really does not allow third-party access to the data or products of their CORS stations. The project does all it can to explain in full detail how the system works (namely, on this website), but in addition a formal Non-Disclosure Agreement will be formulated that should satisfy the needs of the operators and their lawyers. The trouble at present is that the GPSdancer project has no formal legal body that could sign such an agreement, because the IPR holder of the GPSdancer software is a very simple form of foundation (a German "Bürgerstiftung" without legal persona).

The creation of the Geodetic Cloud Computing Service, as operational service of the GPSdancer system, repairs this problem. It has the legal persona to sign such a statement, and is then legally bound by its contents. The NDA agreement will then be part of the service conditions, which makes it officially illegal for the service to access the data and products of individual CORS stations other than via the accumulation of normal equation contributions.

Encryption

All communication between GPSdancer instances is encrypted in a fairly straightforward way. A 64-byte hexadecimal key is determined by each process as a function of its binary (executable) file, its software version, an administrator password that was digested in the binary files, and some similar unique characteristics. This key is computed at run-time by the GPSdancer process. As soon as one byte of the executable GPSdancer program changes, all 64 bytes of the key change unpredictably. In other words, hacking the software to circumvene this protection mechanism already makes it impossible to find the correct key afterwards.

Each outgoing byte of data, transmitted by a GPSdancer process, is XOR-ed to the next byte of the encryption key, byte-by-byte, and returning to the first byte when reaching the end of the 64-byte key. The receiving process also applies byte-wise XOR with the sequence of bytes in the key to restore the originally transmitted bytes. Two GPSdancer processes that do not have exactly the same key will never be able to communicate with each other. Also, hackers need to have a profound understanding of the communication protocols and exchange sequences between GPSdancer processes in order to have any hope of decyphering an intercepted binary data stream.

Irrelevance

The best protection of the GPSdancer network communication is the general irrelevance of its data to hackers, secret services, chinese students and anybody else who may try to intercept the communication streams. More than 99.999% of the exchanged bytes are elements of normal equations. What on Earth can a chinese hacker do with averaged partial derivatives between two model parameters in an orbit estimation process? No private information of a CORS station (input observations, output products) is ever exchanged between the GPSdancer instances, because they do not need these things.

Project details

The GPS Dancer project started in 2007 as a voluntary project of a working group of the International Association of Geodesy.

Square dance algorithm

The GPS Dancer system was named after its "square dance" exchange algorithm. Of course, it also wants to to make the GPS reference frame denser.