User's Guide - Chapter 9: Security
Any time data is exchanged over the Internet security is an issue. TrueUpdate normally relies on Internet communication to update software; therefore, it is also subject to Internet security issues.
This chapter will explain the security measures that have been implemented in TrueUpdate and outline ways in which you can further enhance your update application’s security.
The security of your product is only as strong as its weakest link. For that reason, measures have been taken in the design and development of TrueUpdate to provide as much security as is practical for the product.
Since TrueUpdate was designed to be flexible enough to accommodate your specific updating needs, there are security measures that can only be implemented by you, the developer. In this chapter, we will examine TrueUpdate’s built-in security features and the additional measures you can take to further secure your software updates.
TrueUpdate takes steps to ensure that the update files you distribute with your software are secure. The details of your update application, such as scripts and project settings, are hidden from casual inspection.
In general, you will distribute two files with your update application: the client executable file and the client data file. Below is a short overview examining how these files and the file updating process are protected.
The client executable file does not contain any information specific to your update application. It is a runtime executable that is used by all TrueUpdate users. For this reason there is no special protection applied to it.
The client data file contains your client script, screens and most of the project settings you configured at design time. Since some of this information can be sensitive, the file is compressed and encrypted to prevent unauthorized inspection or tampering.
At run time the scripts, screens and settings in the client data file are read directly into memory, without being written to the hard drive (even temporarily) in any unencrypted form. The only files that are temporarily created by the TrueUpdate Client are not sensitive in nature, and are deleted as soon as the update application shuts down.
Every time you publish your update, the MD5 hash of the current client data file is stored in the server data. This allows the client application to automatically determine whether its data file is up to date. If the MD5 hash of the client data file on the user’s system does not match the one that the server file was published with, the client data file will automatically be downloaded and updated. So, if your client data file is tampered with on the client system (e.g. if it is infected with a virus, or damaged by the user), it will be removed and updated the next time an update is requested.
Your TrueUpdate server files are especially vulnerable because they are usually publicly available on your TrueUpdate servers. For this reason, there are strong security measures in place to protect them.
When you publish your update to a TrueUpdate Server, several files are uploaded. The files all use your custom server file prefix for file names and have the file extensions .ts1, .ts2 and .ts3.
The server data file has the extension .ts1 on the TrueUpdate Server. This file contains all of your server scripts and screens. This file is the most critical security concern as it contains information about how you update your software and may also contain sensitive passwords and file locations.
The server data file is encrypted using private-key Blowfish encryption. The private key is the unique, product-specific key that you specify in TrueUpdate at design time (see Project > Options from the menu.) This private key is stored in the client data file, which is also encrypted using a different encryption scheme.
Only update clients that were built with the same encryption key that was used to encrypt the server data at build time can read the server file. For this reason, it is very important not to lose the encryption key used for an update project. It is also important not to change the encryption key after your update application has been distributed to end users.
Tip: The longer your encryption key, the harder it is to break. It is recommended that your encryption key be at least 20 characters long.
The updated client data file has the extension .ts2 on the TrueUpdate Server. It contains the latest version of your client data file, and is placed on the TrueUpdate Server in case the user does not have the most recent version of the client data on their system at run time. If the TrueUpdate Client sees that the .ts2 file is newer than its existing client data file, it will download the .ts2 file and replace the client data file with the newer version.
Since the client data file is already encrypted, the updated client data file doesn’t require any additional security measures.
The updated client executable file has the extension .ts3 on the TrueUpdate Server. It is a compressed version of the client executable. Like the updated client data file, the updated client executable is used to update the user’s TrueUpdate Client application when the user does not have the most recent version of the client on their system.
Since this file does not contain any of your product-specific information, no special protection has been applied to it.
As you probably know by now, the TrueUpdate Client application normally needs to communicate with a TrueUpdate Server in order to update your software. The question is, what kind of communication takes place?
There is no "default" communication between your TrueUpdate Client and your TrueUpdate Servers. If you build a TrueUpdate project that has an empty client and server script, no client-server communication takes place. All client-server communication is specified through script, whether it is created manually or with the project wizard.
The most common way that your projects will interact with your TrueUpdate Servers is through the action TrueUpdate.GetServerFile. This action downloads the server file you have specified from a TrueUpdate Server and then runs the server script. All of this communication takes place through the protocol specified for the TrueUpdate Server (HTTP, HTTPS, FTP, or LAN).
The TrueUpdate Client never sends information about the client or client system to the TrueUpdate Server. It merely downloads the specified server file, decrypts it and then runs the script. It may also do a self-update if necessary.
Of course, TrueUpdate provides a wide variety of actions that you can execute to perform all sorts of client-server communication over several protocols. The following sections will look more closely at some of these available options.
TrueUpdate provides you with several secure protocols that can be used in both the design and run-time phases of development.
TrueUpdate allows you to use the SFTP (Secure File Transfer Protocol) to upload server files at publish time. SFTP is a transfer method that uses SSH to transfer files using AES, DES, and Blowfish encryption. Unlike standard FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted in the clear over the network. It is functionally similar to FTP, but because it uses a different protocol, you cannot use a standard FTP client to talk to an SFTP server, nor can you connect to an FTP server with a client that supports only SFTP. TrueUpdate’s implementation of SFTP uses SSH2.
The secure hypertext transfer protocol (HTTPS) is a communications protocol designed to transfer encrypted information between computers over the World Wide Web. HTTPS is HTTP using a Secure Socket Layer (SSL). A secure socket layer is an encryption protocol invoked on a Web server that uses HTTPS.
The TrueUpdate Client can transfer files and data from a Web site using the actions HTTP.DownloadSecure and HTTP.SubmitSecure. These actions will ensure that the connection between your client and your server is secure. Note that your Web server must be specially configured in order to support HTTPS.
There may be times when you want your update client to communicate with a Web server in a way that is not built into TrueUpdate. Some examples are:
· validating the user’s serial number against a Web database before providing updates
· tracking which customers have updated the software and when they last updated in a Web-based database
· allowing the user to renew a software subscription through your update client. The client will gather payment data and then submit it to your Web server through the HTTPS protocol for payment processing
· submitting user feedback from the TrueUpdate client to a Web script that in turn emails the information to you
Fortunately, TrueUpdate comes with built-in actions to facilitate this kind of communication, namely HTTP.Submit and HTTP.SubmitSecure. These two actions allow you to send data to a script on your Web server and then receive a response from the server. These actions should work with any type of standard Web server, such as Apache or Microsoft IIS, and with any type of scripting language that allows CGI communication, such as ASP, PHP, Perl, etc.
By providing a method to interface with Web scripts, TrueUpdate gives you the flexibility to add further security features to the client-server communication process beyond the built-in actions it comes with. This ability to utilize any Web scripts you develop greatly adds to the extensibility of TrueUpdate.
When planning product security, it is important to keep the following in mind: even the best security measures can be circumvented. This is clearly illustrated by successful breaches of highly sophisticated security systems such as DVD encryption and secure government communications.
In addition to securing your installer, update application, and perhaps your installed application, you may want to consider controlling the distribution of your installation files. After all, a software thief can’t steal something he or she can’t find.
One final point to keep in mind is that too much security can be a bad thing. While it is important to secure your application to prevent against unauthorized use, it is equally important to allow legitimate users a painless update process.