Two use cases
- Two colleagues working on the same project need to exchange files containing data that have to kept secret. Both benefit from keeping their workflow within R. They are not able to make a secure transfer of such files in cleartext
- A person need regular updates of secret data from a centralized data source. At the source automated R processes can be run to transfer files to that person. There is no methods available to make a secure transfer of such files in cleartext
For both of the above use cases sship can be applied as a tool to obtain a secure transfer of files.
Summary of how sship works
This is a very brief summary of what sship does. A more detailed description of the methods, technology behind it and how to safely use it is found below.
From within an R session a file is protected using strong encryption. After encryption the original content of the file will only be available to those holding the same key used during encryption. Hence, the encrypted file can now be distributed freely keeping its original content safeguarded. Obviously, the key to allow decryption of this file cannot be distributed “openly” which is a problem because any legitimate recipient of the file will need this key to unlock its content. The key itself is therefore also encrypted but by the use of a different key: the public part of a key pair that belongs only to the recipient. This makes sure that the original key can only be unlocked by the recipient’s private key. At this stage both the encrypted file and the encrypted key can be shared (openly) and only the recipient will be able to unlock the original content.
sship also provide tools for the recipient to aid decryption. However, sship is based on widely used and easy accessible key crypto-technology and the recipient may well apply other tools for decryption. R is therefore not a dependency forced upon recipients.
Details on methods and how to safely apply sship
Technical measures to protect content
In sship a file is encrypted following a hybrid scheme: the content itself is encrypted applying a symmetric key algorithm using a disposable key. This key is in turn encrypted using public-key cryptography with a public key provided by the recipient Here, the term “hybrid” refers to that both symmetric an asymmetric encryption systems are used, and the term “disposable” means that the key used in the symmetric key algorithm will only be applied once and never re-used for encryption of data. The public key is associated with a corresponding private key that is kept secret and only accessible by the person owning it (in contrast to the public key that can be shared freely). The encrypted file and encrypted key can now safely be shared openly. After receiving the encrypted files the recipient follow the reverse hybrid scheme: the encrypted “symmetric key” is decrypted applying the recipients private key and then the decrypted symmetric key is used to decrypt the file holding the original content.
Method of encryption consists of generating a randomized 256 bit key every time data is to be encrypted. This key is then used to encrypt data following the Advance Encryption Standard. The recipients public key (that was generated using an RSA crypto system) is collected from his/hers user account at GitHub and used to asymmetrically encrypt the “symmetric key”. The encrypted data and encrypted key is then shipped to the recipient. For practical implementation of encryption and decryption as describe above the OpenSSL cryptography library is applied.
This scheme ensures that data privacy are protected by sufficiently strong encryption also along the lines of the recommendations by the Norwegian National Security Authority and that decryption only can be performed by the recipient.
Organizational measures
Technical measures alone do not guarantee a safe exchange of secrets. The crucial part of applying sship is the exchange of the public key from the recipient to the person or entity that do the encryption (the provider). It is paramount that the recipient is authenticated to the provider. In other words, the provider must be absolutely sure that the public key used belongs to the recipient, and no one else. If this is not the case sship cannot and should not be used for any exchange of secrets! sship collects the public key from an external and open repository based on a user id uniquely defining the recipient (and his or hers public key) at this repository. Such repositories must provide means of authentication (of the recipient) that allows only the recipient to add or alter user profile content such as for instance public keys. In general authentication based on a username and password is not sufficient: multi-factor authentication of users should be enforced at the repository providing public keys to sship. In addition, both the provider and recipient should be part of the same organizational structure at the repository to make sure that they are both under the same “governance” with respect to user management. Currently, sship only supports GitHub as a repository for public keys. It allows for both multi-factor authentication and relevant user management.