This is a continuation of Part 1. To preserve confidentiality in secure file transfers, public keys are given to end users while the private key is kept inside the managed file transfer server. Get a look into how it works with the JSCAPE platform by requesting your free trial.
When a user wants to do a secure file transfer, he simply encrypts his plaintext file using the public key in his possession. Because the file is encrypted, it is kept safe from prying eyes during transmission and the confidentiality of its contents is preserved. As soon as the encrypted file reaches the managed file transfer server, the server decrypts it using the public key’s corresponding private key.
So how does a user get a hold of the public key? Sometimes, a public key is sent by the server to the user’s file transfer client at the start of a secure file transfer. For example, at the start of an FTPS session, the server sends a digital certificate that already contains a public key.
Recommended post: Symmetric vs Asymmetric encryption
Public keys and private keys for authentication
Public keys and private keys aren’t only used for encryption. Because a particular private key and its corresponding public key are related, the public key can be used to verify that a certain private key is in fact its partner. This explains why they are also often used in authenticating clients at the start of a secure file transfer session.
For example, in setting up SFTP, private keys are generated and then are each assigned to authorized end users. If the system is applied correctly, no two end users would have the same private key and each user would keep his/her own private key private. Also, the private keys’ corresponding public keys would be kept in the server.
So when a user logs in by submitting his private key to the server for verification, the server can verify the user’s identity by using the private key’s corresponding public key.
Nailing down the difference between server keys and client keys
After all that discussion about private keys, public keys, confidentiality and authentication, we’re finally ready to differentiate server keys and client keys.
How server keys are used
Whenever you generate a server key via the JSCAPE MFT Server’s Key Manager like this,
you’re actually creating a public/private key pair that would later on be used primarily for encrypting files in secure file transfer protocols like SFTP, FTPS, or HTTPS. In other words, they would be used by your server to preserve the confidentiality of your file transfers.
As mentioned earlier, the public key of this particular key pair is normally sent (sometimes as part of a digital certificate) to the client at the start of a secure file transfer session. The client then uses that public key to encrypt whatever file it sends to the server.
Note: In some cases, server keys can also be used for server authentication (as in the case of HTTPS) or both server authentication and client authentication (as in the case of AS2).
Recommended read: MFT servers explained: Why your business needs one now
How client keys are used
On the other hand, whenever you generate a client key via the JSCAPE MFT Server’s Key Manager like this,
the resulting public/private key pairs would be used for authentication purposes.
In the course of generating a client key, you would be asked to export that client key’s private key
It is that private key which you would send to an end user and, in turn, which the end user would load up to his file transfer client to do say SFTP public key authentication (see screenshot in Part 1).
Summary
Whenever you generate either a server key or a client key, you are actually creating a key pair consisting of a private key and a public key. However, the pair that’s created when you generate a server key is mainly used for encrypting the session (with a few instances wherein they’re used for authentication), while the pair that’s created when you generate a client key is used for authenticating clients.