How to protect data on a solid-state drive (SSD) with SafeGuard Device Encryption

  • Article ID: 113334
  • Rating:
  • 14 customers rated this article 4.0 out of 6
  • Updated: 23 Mar 2016

This article provides information on using SafeGuard Device Encryption with SSD drives.

Known to apply to the following Sophos product(s) and version(s)
Sophos SafeGuard Disk Encryption
SafeGuard Easy
SafeGuard Device Encryption

Operating systems
All supported operating systems

1. How to protect data on a solid-state drive (SSD) with SafeGuard Device Encryption

With SafeGuard Device Encryption (full disk encryption) entire drives or hard disks on your computer can be encrypted sector by sector. This guarantees that no plain text sectors remain. Your computer is fully protected.

To protect a solid-state drive (SSD) with SafeGuard Device Encryption, we recommend that you consider the steps described in this article. These are important due to the specific data managing mechanism of SSD keeping replicas of existing, and deleted data for some time which impacts encryption.

2. How to comprehensively protect data on an SSD

  1. Start initial encryption on an SSD immediately after installation of SafeGuard Device Encryption and before any sensitive data is written to the SSD. In this way, data on your SSD will be comprehensively protected.
  2. Note that decommissioning of encrypted SSDs using the instant decommissioning tool that is provided with SafeGuard Device Encryption may not suffice. The tool overwrites the key storage area, but with SSD data managing mechanisms at work, stale replicas might remain on the SSD. If decommissioning is an issue for you, consider using a self-encrypting/-decrypting SSD (Opal standard).
  3. When an SSD with sensitive data reaches its end of life, consider destroying it physically.

3. Why do solid-state drives (SSD) need special encryption precautions in the first place?

Solid-state drives are flash-based similar to USB flash drives. The drive’s internal controller writes data to pages (“sectors”) whose physical location is unpredictable from outside the disk. Also, if you delete data on an SSD, the pages with the relevant data are marked as invalid by the controller but are not necessarily erased immediately.

That means that on an SSD, a piece of external software does not have complete control over the data, and how or where it is physically stored on the drive. This is quite different from a hard disk drive, where a driver can control exactly what happens to the data at a specific physical location on the disk. The only way to make sure that all sensitive data is really encrypted at any time on an SSD is to make sure that it is already encrypted before it reaches the drive for the first time.

4. Technical details and background information

A recent research paper sheds some light on the sanitizing characteristics of SSDs (see also Chet Wisniewski's blog post). It answers many of the open questions in the context of SafeGuard device encryption:


  • What does 'sanitizing' actually mean?
    According to Wikipedia, sanitization (the noun behind 'to sanitize') is the process of removing sensitive information from a document or other medium. In the context of hard disks, it denominates the reliable destruction of data from a hard disk, so that it cannot be recovered.

  • Can I sanitize an entire SSD with (ATA or SCSI) 'secure erase' or comparable commands?
    Not really. On the one hand, these commands are not consistently implemented on all SSDs. On the other hand, even if implemented, they do not always work reliably. If not, they may fail with or even without returning an error (the latter observed in one case). There is no verification mechanism available.

  • Can I sanitize a file or specific region on a hard disk?
    No, there are no sanitization commands available that would cover less than the entire disk. Classic (regular hard disk) file sanitization mechanisms consistently fail on SSDs. Although a repeated overwriting of an affected sector increases the chance that all stale copies are overwritten, there is no guarantee for that.

  • What is this 'wear leveling' all about?
    SSD pages (this is SSD speak for sectors) have a limited number of write cycles (a magnitude of 10,000) before they wear out. In order to have all pages of an SSD wear out evenly, the SSD controller introduces a level of indirection between the LBA and the actual SSD page with the objective that all pages are used as evenly as possible. This has the consequence that repeated write operations on the same LBA will typically address a new SSD page for every write. The content of the previous page, however, will not be sanitized when a new page is written. These previous pages are not accessible via regular LBA addressing (i.e. over the regular hard disk interface). They are, however, accessible when the flash chips are read outside the SSD. To provide wear leveling, SSDs have a physical storage capacity that is in the magnitude of 10 - 30 percent higher than their nominal storage capacity. According to the research paper, all investigated SSDs provide these redundant pages. According to other sources (HOT), there are SSDs that do not provide redundant storage. However, their behavior when almost full is so unsatisfactory that they hardly qualify for professional use.

  • How critical is the phenomenon of stale copies of data?
    As a consequence of wear leveling, stale copies of files remain when files are overwritten in place (from an LBA point of view). However, even when files are never overwritten, stale copies come into existence as a consequence of SSD-internal data management (garbage collection etc.). Experiments showed up to 16 stale copies of a file that was only written once!

  • How big is the effort to recover stale data from an SSD?
    The authors of the above research paper constructed an FPGA-based reader device for some US$ 1000. They suggest, however, that a cheaper, microcontroller-based version would only cost some US$ 200.

  • Is the sector-to-page translation the only indirection used in SSDs?
    No, some SSDs additionally appear to compress their data (left alone self-encrypting SSDs).

  • Can I efficiently sanitize an SafeGuard-encrypted SSD by applying BEInvVol.exe the decommissioning tool that comes with SafeGuard Device Encryption  (i.e. by only sanitizing the Key Storage Area - KSA)?
    No, because you cannot sanitize the KSA. For the reasons, see above.

  • Is the ATA/SCSI TRIM command able to help me sanitizing an SSD in any way?
    Not really. TRIM only suggests the SSD controller to delete an advertised area. No immediate reaction is guaranteed. It is a hint to the SSD's garbage collector, which may react with some delay or not at all.

  • What does this all mean in the context of SafeGuard initial encryption of a volume?
    I think we have to distinguish here between regular initial encryption and fast initial encryption:
    • With regular initial encryption, all LBA sectors, hence most pages of an SSD, will be touched and written, Since the SSD has only a limited (relatively small) amount of redundant (wear leveling) pages available, there is relatively little space (some 10 - 30 percent) left where stale data can end up. Bad enough though.
    • With fast initial encryption, only a subset of LBA sectors will actually be written. If the allocated space makes up a small part of the disk capacity only, there is a good chance that:
      • Most or all of the original (plain text) content survives.
      • Most or all of the deleted file areas of the file system with plain text contents survive (depending on the pre-SafeGuard history of the SSD)
      • Please note that the above arguments have been made under the assumption that there is only one volume present on the hard disk that spans all available disk space. With more than one volume, inter-volume effects would come into place.
    • Explicit TRIMming tools (e.g provided by the SSD vendor) that are executed right after a regular initial encryption can perform the necessary clean up of deleted file areas. However, we cannot verify their proper operation. (There is, for instance, the Intel SSD Optimizer from the Intel SSD Toolbox)

  • How does the SSD's garbage collector (see above) work?
    We don't know in detail. Apparently, it tries to identify and delete unused space when the disk is idle. A paper on forensics with SSDs suggests that some modern disks (the authors explicitly state Samsung) analyze NTFS partitions on the disk and delete free space based on the free space bitmap (which implicitly also means that - on an encrypted volume - this advanced garbage collection can't work). Most likely, the host has no control over any garbage collection activities whatsoever.

  • Is there no way to sanitize stale (remnant) clear text data during or right after initial encryption?
    Well - not for us. The authors of the research paper developed sanitization algorithms based on a firmware Flash Translation Layer (FTL, basically a superset of the wear leveling algorithm) from Microsoft Research. These algorithms could help us efficiently. However, currently there are no indications that the SSD vendors will adopt these algorithms.

An interesting view from the opposite side (this is, unwanted decay of forensic data on SSDs) is given in the aforementioned SSD forensics paper.

If you need more information or guidance, then please contact technical support.

Rate this article

Very poor Excellent