Protect yourself from closed source SSH

Encryption is important, but you should know the dangers of using encryption software that cannot be closely examined -- and how to mitigate those dangers when you have no choice but to use it.

A basic understanding of the practical realities of privacy technologies should include an understanding of why encryption that doesn't trust the user isn't trustworthy. There are times, however, that we must make do with less than ideal choices for security software. One such example is that of performing secure file transfers on a wireless network with an Android smartphone. Because the Android OS does not offer users an instance of OpenSSH as part of the standard system, and because there is not an open source SSH-based file transfer client or server application in the Android Market, the common choices are to either use a closed source tool or not use SSH on an Android device for file transfers at all.

The problem is not limited to SSH software. Any closed source software involved in the process can be a problem, from the operating system on which the SSH software is running, through password managers and any special "multimedia key" management applications for keyboards, all the way to the encryption software itself. As long as such closed source software ties into key parts of the trusted chain of operations, there is little that can be done to ensure that what should be private remains private.

Of course, open source software provides no 100% guarantees. Its benefits merely revolve around a much greater chance that any data leaks or malicious software designs are more likely to be caught, especially given that -- unlike the case of closed source software -- open source development is not typically performed by a set of employees operating under nondisclosure agreements. A community of people with equal access to the source code, many of them operating independently and some even with strong motivations to discover and publicly reveal vulnerabilities, makes for a very difficult place to hide malicious security compromises in your code.

On the other hand, in many cases the biggest privacy concern is not the data you wish to transfer from one system to another. In such circumstances, perhaps the potential for someone to read the data you transfer from one system to another based on unencrypted data leaks and backdoors do not concern you much. While it is generally better to securely encrypt all data on the off-chance malicious use can be made of it outside the expectations of the person transferring files from one system to another, the simple necessity of transferring files may override "just in case" measures that are most likely unnecessary.

The matter of secure authentication is still important, however. When transferring files, the very act of authentication on the remote system required to gain access for a file transfer operation can make the target system vulnerable. If the software used to establish the connection leaks data somehow, the authentication information itself could be compromised -- and could subsequently be used to gain unauthorized access to the remote system.

While trying to cover up these dangers with masking tape is an imperfect response, imperfection is sometimes better than nothing at all. In that spirit, some measures can be taken to mitigate that danger:

  1. Never transfer files one would not trust in the hands of a stranger, including the developers of the closed source software you use.
  2. Set up a secure file transfer account with rssh so that compromise of the account will not provide direct shell access to the system.
  3. Use the find utility to scan for writable directories on a regular basis, to ensure that if unauthorized access is achieved the account used to access the system will not have the correct permissions to affect other parts of the system.
  4. Set secure file permission defaults, again to employ the system's privilege separation capabilities to limit the effects of unauthorized access to the system.
  5. Use integrity auditing frequently to ensure the system has not been compromised.

Some of these measures are just smart security practice, but they become especially important for the case of using SSH via untrusted tools such as a closed source SSH client when connecting to the system. Additional options are available as well, including one-time passwords. Another measure can be taken that may be the most effective of all such mitigations -- but also the most onerous -- and thus deserves special mention:

Creating a special user account just for the purpose of making file transfers, moving files out of that account so they will not be vulnerable to unauthorized access, and replacing the account with a new one with a new password on a regular basis, helps eliminate opportunity for even compromised authentication data to be used maliciously. This approach may prove impractical, because the administrative overhead involved in taking such steps becomes prohibitive in a hurry when such file transfers are performed frequently or when many such accounts need to be maintained in parallel.

Obviously, the best option is to avoid using closed source encryption and privacy software altogether. If that is not a reasonable option, however, any measures that can reasonably be taken to mitigate the danger of trusting software distributed by people who do not trust the users should be taken.

In some cases, avoiding use of the network altogether is the only reasonable way to mitigate the danger of file transfers. Unfortunately, using common portable storage devices to transfer files -- such as USB flash storage media -- is a solution that has its own problems.