SECURITY CONTEXT
To understand the security of CrashPlan, it helps to have a high-level familiarity within the context of how CrashPlan works:
1.CrashPlan backup begins with the client recognizing file modifications made by the user in real time. Files are analyzed quietly in the background to identify what is unique about the change. Unique information is broken into blocks, then compressed and encrypted symmetrically using a local archive key.
2. The encrypted information flows through a secure communications channel to multiple destinations asspecified by an administrator.
3. Data remains in its encrypted state on disk, at the destination. Decryption occurs only when authorized personnel supply the password or archive key to restore the data.
4. CrashPlan restore begins when the user or administrator selects files to restore. Encrypted blocks are received by the client, decrypted using the local archive key,decompressed and written out locally to disk to complete the file recovery process.
Technology
CrashPlan executes within the confines of a secure Java virtual machine. All cryptographic functions rely on the industry standard Cryptographic Extensions (JCE) provided therein. There are numerous security benefits to this architecture, including:
Type safe execution
Only secure, type safe byte code is executed, providing protection against buffer overflows and similar mistakes traditionally exploited by attackers.
Open model
Rather than relying exclusively on "security through obscurity," the cornerstones of our security frameworks are available via open-source for peer review.
Comprehensive security framework
The JCE has been widely reviewed and deployed in countless enterprise applications.
No comments:
Post a Comment