Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Purpose

This purpose of this document is to describe the security safeguards used to protect client data when they use the Send Data to Tech feature of the various MCS Applications.

MTD Format

When data is sent using the Send Data to Tech feature, it is always sent in an MTD file.  MTD stands for MCS Tech Data.  It is a format designed explicitly for keeping data sent from clients as secure as possible.  The MTD format is, in reality, a specially formed Zip file, renamed to have the extension MTD so that it can easily be distinguished from normal Zip files.  MTD files contain a file named CIPHER.KEY, which is not password-protected by the Zip file.  All other files in the MTD file are password protected using AES-256 encryption.  The AES secret key is generated randomly on the client workstation that creates the MTD file.  This randomly generated secret key is encrypted using RSA 2048-bit public-key encryption, using a public key hard-coded into all MCS Software applications, and stored in CIPHER.KEY in the MTD file.  The workstation that generated the secret key then discards the secret key that it generated.  The private key that corresponds to the public key used to encrypted the secret key is not available to anyone, but exists only on a secured server owned and operated by MCS Software.  No MCS employees are in possession of the private key; and, only 2 system administrators have access rights to log into the server that does possess the key.

Transmission

MTD files are transmitted to MCS via HTTPS, with the exception of one legacy application, WinFSCM.  WinFSCM uses FTP to transmit the MTD file.  FTP is not secure and it is possible for a 3rd party to intercept the MTD file when transmitted using FTP.  However, an MTD file is in and of itself, encrypted at higher levels than most secure file transfer protocols (for example, most HTTPS servers use AES-128 to encrypt the data, and an MTD file is already encrypted using AES-256, which is stronger).  Both the HTTPS methods and the FTP methods are using servers that allow write-only operations.  Read operations are not permitted for any users on these servers.  The MTD file can be downloaded to MCS employee workstations using a secure FTP client (using explicit TLS encryption to protect both the data and the user/password credentials) from an internal FTPES the server (which holds the MTD files sent by customers via the public HTTPS / FTP servers).  Once again, the MTD file is considered secured in and of itself.  The transport-layer security here is an extra measure of security that is primarily intended to protect the login credentials.

Decryption

The purpose of sending a file in the MTD format is to provide sensitive client data to MCS Software employees.  To this end, MCS employees have access to a utility that can extract MTD files.  This utility can only be used from pre-authorized workstations using the secure credentials (username and password) of the MCS employee that is trying to extract the file.  It is impossible to use this utility without the real-time cooperation of the MCS Server that possesses the secret key-- even with the source code to the extraction utility.  The utility works by sending the very small CIPHER.KEY file contained in the MTD (which is not password-protected by the Zip file, but public-key encrypted before being zipped), along with the required credentials to the MCS server.  The server validates the credentials, decrypts the CIPHER.KEY file using the private key that it alone has access to, and returns the randomly generated secret-key that works only for this particular MTD file to the utility.  The server logs every attempt (both failed or successful) to decrypt a CIPHER.KEY file.  The extraction utility then decrypts the remaining AES-256 encrypted files locally using this secret-key returned by the server.  The secret-key, which is only valid for the single file it came from, is then discarded.  In the case of database backups, the extraction utility automatically restored the database to the MCS employee's workstation and then deletes the temporary database backup from the hard-drive.  This effectively limits the unencrypted data in existence on the workstation to only the currently restored backup.

If an authorized workstation were to become physically compromised (lost, stolen, or destroyed), we have the ability to revoke it's authorization centrally.  If a thief was in possession of an authorized MCS machine (for example, during the brief period between the loss and the loss being reported to MCS system administrators) he or she would have to have knowledge of an MCS employee's username and current password to perform an extraction.  If, in the extremely unlikely event that a thief managed to gain access to both an authorized machine without our knowledge; and a valid username/password pair, they still would have to have the server's cooperation, which means we would have a log of what data was extracted on what date, from which machine, with whose credentials, and by what IP address.  This log would enable us to provide law-enforcement officials with valuable information for recovering the compromised data and allow us to notify any customers if their data was compromised or potentially compromised.

Rationale and Explanations

This may, at first, seem over-complicated.  There are drawbacks to both types of encryption (secret-key and public-key, aka "symmetric" and "asymmetric" cryptography, respectively) when used independently.

  • Secret-key encryption requires pre-sharing a key to both parties, which is often not possible without potentially compromising the secret key (if either party inadvertently discloses the secret key, then the entire encryption is compromised).  If a pre-shared secret key were used, a hacker could reverse-engineer our executable and potentially extract the secret-key.
  • Public-key encryption (at least the RSA algorithm, which is the only widely accepted public key cryptographic method known) is only suitable for small messages (several hundred bytes).  We very often need to be able to securely transmit very large files.  Furthermore, public-key requires both the private key and the encrypted data to be available to the same process in order to be decrypted, and the private key is stored on a very secure server that is not accessible by nor has access to the MTD archive files.

By using public-key encryption to protect a randomly generated secret-key, and the secret-key to protect the sensitive date, we can overcome these problems and create a very secure file.  This technique is commonly referred to as a digital envelope.  Using this technique, we have effectively made it impossible (or mathematically infeasible) to decrypt the contents of the MTD files, by any workstation, whether owned by MCS or the client who created the file, or even developer machines with access to all MCS source codes.  It can only be decrypted with the assistance of the MCS server that contains the RSA private key.

  • No labels