Last time, I introduced you to one method for securing data at rest and that was by deploying encrypted file systems. As promised, this post will focus on another method, known as PGP encryption. Although encrypted file systems provide a decent level of protection for your data, they have certain limitations.
The weakness of encrypted file systems
For one, because credentials of encrypted file systems are normally stored in the same machine as the data itself, there is still that risk of a data breach. For instance, if you manage a server that employs an encrypted file system and that server’s hard disk is stolen, it would still be possible for the thief to acquire all the information inside once he has acquired the credentials that came with the disk.
Obviously, it would be much safer if your credentials were placed in a different location. That’s one significant advantage that PGP has.
What makes OpenPGP encryption better
In a typical OpenPGP encryption system, users start by creating two keys: a private key (a.k.a. a secret key) and a public key. As its name implies, the public key is shared with the public. To be more specific, a user (let’s say, UserGuy) shares it with anyone whom he would like to accept encrypted data from.
Generating OpenPGP keys in JSCAPE MFT Server
When a piece of data is encrypted with UserGuy’s public key, only the person who holds UserGuy’s private key can decrypt that particular piece of data. Of course, ideally, that person should only be UserGuy and UserGuy alone. That’s why UserGuy should put his private key, which serves as one of the "credentials" in this case, in a secure place.
Now, let’s say you manage a server that stores a collection of data owned by multiple users, including those owned by UserGuy. If a crook steals your server’s hard disk, he won’t be able to access any of the data inside unless he has a user’s private key.
Naturally, each user will have stored his own password protected private key in a separate location. So that, even if the crook is somehow able to get hold of UserGuy’s private key and the credentials protecting the key, the crook will only be able to access UserGuy’s data. The data owned by the other users will remain encrypted and safe.
Another nifty feature that comes with PGP is its ability to support digital certificates. Basically, PGP allows UserGuy to affix a digital signature to a public key that certifies UserGuy’s ownership towards said key. Other people can likewise affix their digital signatures on the same public key to vouch that that key really belongs to UserGuy.
This is important because, without this feature, if a crook pretends to be UserGuy, he (the crook) can share his own public key to UserGuy’s friends and those friends will think what they got was UserGuy’s key. As a result, those friends might encrypt data intended for UserGuy but will end up sending them to the crook instead.
With digital signatures, it would be very difficult for crooks to fool UserGuy’s friends. Thus, when UserGuy’s friends encrypt a confidential piece of information using UserGuy’s digitally signed public key, they can be sure that only UserGuy will be able to decrypt it.
OpenPGP in JSCAPE MFT Server
JSCAPE MFT Server already supports OpenPGP. Basically, when a user uploads a file to an OpenPGP-enabled JSCAPE MFT Server, that file can be automatically PGP-encrypted. If you’re in-charge of managing a JSCAPE MFT Server, you can take advantage of the PGP features either by using triggers or OpenPGP-encrypted virtual directories.
The beauty of JSCAPE MFT Server’s OpenPGP feature is that most of the processes associated with encryption/decryption and the use of digital signatures are already automated, especially from the point of view of the end user.
Here’s a simple scenario of OpenPGP encryption on your managed file transfer server using triggers. Let’s say UserGuy wants to PGP-encrypt each file he uploads.
At the client’s end, UserGuy starts by creating PGP key pairs using a PGP client (e.g. GPGTools). He then exports the public key and sends it to you.
At the managed file transfer server’s end, you import UserGuy’s public key using JSCAPE MFT Server’s Key Manager.
You then prepare a trigger-based PGP encryption by creating a trigger that:
listens for the File Upload event,
performs the PGP Encrypt File action with the condition that the uploader’s username is UserGuy, and
uses UserGuy’s public key for encryption.
Thus, when UserGuy uploads a file, the system will automatically encrypt his newly uploaded file using his own public key. Remember, that file can only be decrypted using UserGuy’s private key.
Because UserGuy’s private key is not stored in your server, a crook who manages to break into your server won’t be able to view UserGuy’s files. In effect, you were able to provide data at rest protection to UserGuy’s files.
That was of course a very simple scenario. You can configure more sophisticated triggers such as one that encrypts files uploaded by a certain user and then notifies another user through an email.
Another way of using PGP encryption in JSCAPE MFT Server is by enabling a virtual path to PGP-encrypt all files that are uploaded to it. In this case, all files (regardless of filename, filetype, username etc.) that are uploaded to that directory will be automatically encrypted.
Combine these OpenPGP features with secure file transfer protocols like SFTP (SSH File Transfer Protocol) or FTPS (FTP over SSL), which are also supported by JSCAPE MFT Server and JSCAPE’s file transfer client (AnyClient), and you’ll be able to secure your users’ files both as data at rest and as data in motion.
That's all for today. I hope you learned something from this post and I look forward to see you again here next time.