We are constantly refining our security measures to meet the rapidly evolving threats in the digital space (like viruses, attackers, hackers and all the other bad guys snooping around the internet), as well as to protect against the every day disasters that Murphy's Law provides us (like fires, floods, thefts, and accidents). We apply classic principles of secure programming with the knowledge of the latest advances threats and countermeasures. Sometimes the principles sound vague, but below we explain them and identify some of the ways in which they are employed. We would rather you understand why your data is more secure with ElephantDrive than just take our word for it.
First, we harden every server and network device and place it in the secure ElephantDrive datacenter. This means applying the time-tested security principles of "Least Privilege" and "Economy of Mechanism." In simple terms, it means we remove every program and close every port that isn't absolutely necessary for our systems to operate, and we restrict physical access and enforce strict rules regarding the environment in which the machines are kept. It's sort of like the military principle of information on a need-to-know basis. Unlike your home or office computer, ElephantDrive machines are there to serve one, and only one, purpose - securely storing and managing your data. There are no additional programs for hackers to exploit. Our computers are housed inside locked cages in a temperature-controlled facility with redundant power, connectivity, and fire/flood protections. Access is monitored and granted to authorized-personnel-only, and food and drink are prohibited. These efforts enable us to dramatically reduce the potential avenues of attack for would-be wrong-doers and the chances of freak accidents.
Second, we insist on persistent authentication at the most granular level. This involves applying two other established security principles, "Fail-safe Defaults" and "Complete Mediation." In other words, we start by assuming that all requests for information we receive should be denied, and then evaluate whether or not to grant permission (rather than the other way around). Then we apply this analysis to each individual request. For instance, if an ElephantDrive client wants to upload a file, the software not only verifies the client's identify before the file begins its transfer, but with each chunk of information delivered. This vigilance also helps us to dramatically reduce the opportunities for the bad guys to impersonate a client.
Third, we compartmentalize sensitive data, in accordance with the principles of "Separation of Privilege" and "Least Common Mechanism." This means that wherever possible we split sensitive information into pieces that are insufficient to reveal anything without their corresponding part, and we keep functionality in narrowest scope possible. A commonly understood example of this that the movies and the military have combined to provide is the use of two independent keys or codes to allow the launch of weapons - one without the other is useless. The best example of this principle in action is a result of our encryption processes. Every file you store with ElephantDrive is encrypted before it ever leaves your computer, and the file and the key with which it was encrypted are stored on separate devices. Furthermore, the ElephantDrive team members separate their administration responsibilities such that the individuals responsible for managing the file do not overlap with those managing the keys. The result is that all files handled by ElephantDrive are completely unreadable by the bad guys, even in the unlikely event they were able to get a hold of the hard drives holding the files.
We are often asked about the strength of our encryption, so here is a little more information. ElephantDrive files are encrypted with the Advanced Encryption Standard*, also known as AES*, using a 256-bit key*. The key is derived from the file itself. Banks and other institutions handling sensitive data use these similar encryption methods to keep your data secure. The key itself is then encrypted with AES, using either another key provided by ElephantDrive or one of your own choosing, and stored separately, as mentioned above. It is worth noting that should you choose to use your own key, no one at ElephantDrive (not even all the employees working in concert) will be able to access the contents of your files.
Once the files are encrypted on the local machine, these are then transferred over to our servers via a 128 bit SSL (secure sockets layer) channel. This provides an extra layer of security while the data is being transferred from the local machine to our servers.
Lastly, we work hard to be open about the security we provide and make it practical for our users. The first guiding principle here is known as "Open Design." In lay terms, this means decoupling the mechanisms we use to provide security from the keys we use to enforce the protection. By making the system details transparent we 1) allow our systems to be examined by experts and reviewers who can offer us feedback on future theoretical attacks or existing vulnerabilities, and 2) need only protect a small amount of discrete information. The second rule applied here is "Psychological Acceptance." This means the security protocols we've chosen to implement have to be simple enough to be understood by our end users, and easy enough that we can actually count on you guys to follow them. Hopefully this explanation has helped to provide a better understanding of how we work with you to practice security, and hopefully our software will make it straightforward and painless for you to execute on it.
Never share your password with anyone. ElephantDrive employees will never ask you for it.
Register now and start protecting your valuable data.
* ElephantDrive is available on many devices and platforms, with varying levels of on-board processing power. Through our desktop and mobile clients, files are always encrypted using AES-256. For some processor-limited devices (including many NAS units), our software will dynamically switch to the less intensive DES algorithm in order to maintain performance levels but still provide at-rest and pre-transfer encryption. In all cases, the application logs will include a reference the algorithm implemented.
We are in the process of updating our software to allow users to explicitly choose which algorithm is employed. We apologize for any confusion on this matter.