Client Authentication

Generally, output streams associated with TCP, UDP, and REP ports are transmitted to a client computer whenever the client makes a connection to the port. In the default Non Authenticated Mode no action is needed beyond establishing the connection. Any client who can contact the NetRS can activate the data stream. This may be acceptable on a secure, limited-access network. But in a less secure environment, such as a NetRS on a full Internet connection, such open access may not be desirable. In such cases you can require Client Authentication on I/O streams so that only authorized clients can trigger the streaming outputs.

Client Authentication involves setting up a Key in the NetRS receiver which is shared with the clients who are authorized to activate the I/O streams. When a a client makes a connection to a streaming port on the NetRS, a Challenge message is issued to the client. Using the shared Key, the client creates and sends a response to the Challenge. Once the NetRS is assured that the client possesses the Key, it begins transmitting the data. Note that the data in the stream is not encrypted.

Creating the Client Authentication Key

Client Authentication Keys consist of 7 non-whitespace ASCII characters. Any combination of printable alpha-numeric or punctuation characters can be used. For optimal security, a good key should not be a normal word, but rather should include a mixture of letters, numbers and punctuation marks. This makes it more difficult for someone to determine the key by trial and error.

The key is entered from the Browser Interface by accessing the menu item I/O Configuration -> Client Authentication. This brings up a page with a text entry field for the Key. The entered value will not be visible. For confirmation, you must enter the same key twice. Click the OK button to accept the value.

Activating Client Authentication on an I/O Port

There is a Require Client Authentication checkbox on the Port Configuration page for each TCP, UDP or REP port. This must be checked to activate the Challenge-Response system on a stream. The OK button must be clicked to make the change official.

Note that each stream has its own control for this feature. Thus it is possible to require Client Authentication on some streams but allow open access to other streams. For example, you might want a secured Binex stream along with a general access to the Ephemeris or Almanac data.

The Challenge Response Protocol

When a client first connects to a port that is using Client Authentication, the NetRS will immediately send a Challenge string as the first packet. The string will be of the form

    NetRS SN1234567890 SysName 04c1e109b489cce8
The first three fields identify the receiver that has been contacted. In this example it is a NetRS, with serial number 1234567890, which has been given a system name of SysName. The final character field is the Challenge. It is a randomly selected, hexadecimal encoded, 64-bit value. To respond to the Challenge, the client must use the shared Key and a DES encryption algorithm to encrypt the Challenge into a new 64-bit value. That value, as a hexidecimal string, must be transmitted back to the NetRS. If the NetRS receives the expected response, it will begin transmitting data.

If the wrong response is sent to a TCP port, then the TCP socket connection will be closed immediately. On a UDP port, the wrong response will lock out the client port until the UDP timeout elapses.

Encrypting the Challenge

The algorithm used to encrypt the Challenge is based on the Unix/Linux standard encrypt(3) function. This function uses a 56-bit key to encode a 64-bit value into an encrypted 64-bit value. Similar functions are available in public domain libraries for non-Unix platforms.

The exact implementation of the encryption algorithm is best shown by a sample program, which is available here. This program can be used to open a UDP connection to an arbitrary port on a NetRS. It will detect and respond to Client Authentication requests. If a Challenge is received, it will query the user for the Key string and use that string to generate the proper response. Once the stream is authenticated, the program will read packets from the UDP stream until it is terminated.

The sample program was designed to be insensitive to platform bit order. It assumes that you are using the GCC compiler, which supports the data type unsigned long long which is a full 64 bit value.

Here is a sample Challenge/Response encryption that can be used to verify proper operation of any implementation of the algorithm:

Challenge 2ddf5d195851429b 16 character Hex encoded
Key theKey! 7 character ASCII
Response 7b0a9a39c66fe703 16 character Hex encoded

Top