by Xiliary Systems Ltd.
Our client wanted a customer-facing secure file transfer system. The major requiremens included high security, custom branding, and audit capability.
The security requirement was very high as files sent by this system could potentially be very sensitive. We provided an extra layer of end-to-end encryption where only the sender (our client) had the key to decrypt the file. This meant not even our Xiliary staff could decrypt files and our client had full control of who they shared the decryption key with. We also included the ability to set a timeout for a file, after which the file would be made unavailable. We also allowed the number of downloads to be restricted to a certain number. Both of these mechanisms to make files unavailable reduce the expose of sensistive data.
It was important for our client that we could also put their company branding over our system to ensure our client's customers had high visible assurances they were working with an approved system.
In addition, our client wanted the ability to audit when and from where their data was being accessed from. The transfer system records this information and our client can view a chronological list of all files, access dates, and download IP addresses.
This file transfer system has been deployed for other insurance companies since and is still in use years later.
Try out the Secure File Transfer System here: swyfle.com
and contact us here brendan@xiliary.com
Security Considerations
Web Attacks
Based on a thorough review of the system, no vulnerabilities to Cross Site Scripting (XSS) attacks or SQL Injection were found. This is largely based on the underlying Django framework which has built-in protections against these attacks. No potential for Cross Site Request Forgeries (CSRF) was found.
Random Number Generation
Randomness is generated in the SJCL library by a derivative of the well-known random number generator Fortuna. It collects entropy into a pool from events that occur in the system.
Key Derivation
A 128-bit key is derived from a password (the password used to protect the file) using a Password-Based Key Derivation (PBKDF) function. The function that is used is PBKDF2, which is a standard algorithm. The function is set up to run 10000 iterations of a HMAC built from SHA-256 in order to frustrate dictionary attacks. Essentially this means that the function is very slow which means that it is time consuming to try a given guessed password.
Encryption
The block cipher AES with a 128-bit key is employed for encryption. It is used in the CTR (Counter) mode of operation. CTR mode involves encrypting a counter value and XORing the block with the corresponding plaintext block. One of its advantages is that is facilitates random access so one can decrypt a given block of the file without having to decrypt all preceding blocks. CTR mode requires an initialization vector, a block of random bytes. This is generates using the random number generator described above.
Integrity Protection
It is imperative to be able to verify the integrity of the plaintext i.e. to ensure that it has not been maliciously tampered with. A Message Authentication Code (MAC) is an algorithm that assists us with this goal. The system uses a an authenticated encryption mode of operation which integrates encryption and a MAC. The particular mode the system uses is CCM - Counter Mode with a Cipher Block Chaining (CBC) MAC. It is setup to have tag lengths of 64 bits. However in CCM, the MAC is applied to the plaintext. This is less satisfactory from a security perspective than applying the MAC to the ciphertext, which other modes like GCM use. It would be recommended to move to GCM in a future version of the software.