Smartphones

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.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

8 comments
mwclarke1
mwclarke1

Not sure about SSH, but any of those SSL certs you get from the top trusted providers, They have to maintain and provide upon demand the private root/chain keys used to generate server Certs. That way if uncle sam needs to monitor some secured transaction or decode a captured session they will be able to do so. That is why several goverment agencies themselves only deploy self signed certs in their organizations :-)

Dukhalion
Dukhalion

I read somewhere that american encryption technology may not be exported without giving the CIA a backdoor or other decryption method to the system. And anything CIA has, someone else can also get their hands on.

pgit
pgit

I have zero experience with android... are you saying I can't install my Linux tools like OpenSSH on android? I'd almost rather have a win7 hand held device than an android, if it isn't compatible with Linux in general... The only reason I would consider a hand held device would be to use SSH for remote admin... maybe it'll be an ipad after all. : \

AnsuGisalas
AnsuGisalas

It seems to me that that kind of task is something that could be automated... do I smell an app there? Something to spawn the new user account with a simplified user input, handle the content, act as a password manager for that account, remind to wipe files, remind to throw away account. Should have no more problems with it than password managers.

Spitfire_Sysop
Spitfire_Sysop

This article makes me wonder if you have reason to distrust the implementation of SSH offered by Google? Have you done any traffic analysis on an Android device?

apotheon
apotheon

I feel your pain, believe me (else I would not have been inspired to write this article, and another that was just published in the Open Source column that is more specifically about Android's lacks). Still, there are many reasons I would rather have Android than Apple iOS, like the more generally developer-friendly environment.

apotheon
apotheon

It very well could be an automated process handled by a specialized application, and should be if you do it more than a couple times. I've done this exactly once in the past, though, and am planning to do so exactly one more time (this week), though -- and the one more time I'm planning to create such a throw-away account is only for the sake of protecting a system while I work on some stuff involving closed source software and SSH for another TechRepublic article. The demand in my life is not high for this kind of protection. Maybe I'll write an admin script to automate the process if the inspiration strikes, though -- and, if I like the results enough, maybe I'll turn it into a fairly usable tool worth sharing with others. If I did that, it could even become the basis of another TR article. We'll see, I guess.

apotheon
apotheon

To my knowledge, there is no Google implementation of SSH. There are third-party implementations that run on Android. One is ConnectBot, as mentioned in the article, which is open source but only offers remote shell access, and another is andFTP's implementation of the SSH protocol for file transfers, but it does not support remote shells and is closed source. I've seen other closed source implementations as well, but nothing actually produced by Google itself. If you know of a Google implementation of SSH, please let me know where to find it.

Editor's Picks