File Share Encryption

 View Only
  • 1.  PGP and SSD Wear Leveling

    Posted Feb 14, 2011 10:06 AM

    I have been doing a fair amount of research on the impact of software based whole disk encryption solutions such as PGP.  As SSDs become more prevalent, it is critical that SSD drives based on MLC function correctly with software based WDE solutions.

    Besides the enormous performance drop associated with software solutions (even with the AES acceleration, PGP's 10.1 engine is nowhere near unencrypted speeds), I have read several whitepapers that mention WDE prevents the SSD controller from correctly wear leveling, resulting in premature failure of the drive.  From my understanding, this is caused by the drive appearing to be full at the hardware level due to the encryption spanning the whole disk.  Since not all SSD vendors use static wear leveling, the  it is stuck segment swapping/rotating/shifting in the area of the disk intended to only be used when it is entirely full.  

    This in turn causes the NAND flash cells  in the reserved leveling area to reach their write limits much sooner than if the drive were not encrtyped with WDE.  Normally a drive wthat is 40% full and can use the remaining 60% free space for wear leveling and it will use the reserved aspace only when the others are utilized..

    Does PGP address this problem in their WDE solution?  

     



  • 2.  RE: PGP and SSD Wear Leveling

    Posted Feb 14, 2011 09:11 PM

    SSDs are a bit of a long discussion, but I'll cross-post and expand upon an answer I wrote in the Mac WDE forum.

    We introduced AES-128 support, multi-processor support, and other performance enhancements (including AES-NI on Windows) to help SSD performance. We're working on other optimizations, but there are some fundamental challenges - for example, by default WDE encrypts an entire disk, even unused sectors. This improves security, since an attacker can't tell an empty drive from a full drive. However, this writes to every sector of an SSD and makes every future write a re-write - which are significantly slower on SSDs.

    To combat this, we introduced a command line option: --fast. If you encrypt using this option, it doesn't encrypt blank sectors. Due to security considerations, this is an advanced option only available on the command line.

    If two drives are encrypted with --fast, it's easy to tell which has more data (and therefore which to attack). A fundamental premise of encryption is to obscure the value of the content, so a blank document and a document full of text should be indistinguishable (see Wikipedia's entry on block cipher modes of operation for an interesting example of what happens when this goes awry). Using --fast leaks information that could be useful to an attacker, so (as security people), we don't like it.

    I've heard very mixed reactions to this option from customers: generally, it sounds good at first, but then customers consider the above and decide not to use it. I'd be interested in your input on whether you would use this - also, what could we say to provide the "average" user with enough information to make an informed security vs. performance trade-off without it being too much detail?

    Bryan Gillson
    Sr. Director, Product Management
    Encryption
     



  • 3.  RE: PGP and SSD Wear Leveling

    Posted Feb 17, 2011 01:27 AM

    Bryan,

    Thanks for the detailed response, it is much appreciated.  I will have to edit that first post since it was riddled with typos! 

    I was aware of the performance enhancements that are available now with 10.x, 128bit AES instead of the stronger 256bit previously offered, multiprocessor support and the AES-NI instruction set support.  These did make a noticeable difference over 9.x, however SSDs have absolutely skyrocketed in performance.  I understand it is difficult to keep pace when the performance targets are doubling every year it seems.  

    I did not however know about the --free switch. When the option --fast is used, the encryption method is no longer whole disk, but rather volume based if I understand correctly?  Now obviously this reduces security since it gives up the exact locatoin of the data on the disk, however this may be an acceptable solution if it helps prevent premature wearing and/or failure of SSDs lacking static leveling.  

    Was the --fast switch a performance improvement that PGP has implemented or was it a workaround to address the wear leveling problem I inquired about?  Or ideally, both?  I'm curious since my primary concern.

    From my personal perspective on a home machine that contains little to no financial or other sensitive data, I would take the tradeoff if it mitigates the risk of premature failure from excessive read/write cycles on a concentrated cluster of NAND cells.  The reason for encryption is to protect my basic personal information from the 99% of people in the world should my computer ever be stolen or lost at an airport. 

    As for how to relay the tradeoffs to average home users, that's an inherently difficult problem since the topic is so highly technical and if I had a good answer I would probably be working for Symantec!

    Looking forward to your response.



  • 4.  RE: PGP and SSD Wear Leveling

    Posted Feb 17, 2011 03:31 AM

    Voxel, I don't recall a discussion about SSD wear leveling impact at the time --fast was implemented. It certainly helps speed up initial encryption, addresses the re-write problem and may help further by allowing TRIM to continue knowing the correct location of the end of usable data (I haven't tested this myself, so it may or may not affect TRIM. It makes logical sense though).

    To be clear, I've not seen the whitepapers you referenced and so can neither confirm nor deny that FDE has an impact on SSD drive life. It's not something I've received a complaint about, either. I'll ask the product manager for WDE about it though. If you do have links or references, please send them my way via email - my address is formatted as firstname_lastname at symantec.com.

    Thanks,

    Bryan Gillson