如何安全擦除SSD驱动器?


36

我对SSD技术还很陌生,所以在安全擦除驱动器时,我不知道它与硬盘驱动器的比较。是否可以运行磁盘工具并使用“用零覆盖”选项擦除驱动器,还是专门为硬盘驱动器设计的?还有其他应采取的措施吗?

不过,我并不是在寻找NSA级安全性,而只是在退货或出售Mac时会做的擦拭。


您是否需要擦除数据,还是需要说服其他人该数据已被擦除?如果只需要说服自己数据已消失,则应尝试使用ATA命令安全擦除。如果您需要说服其他人,则可能需要使用磁盘切碎服务。
2011年

Answers:


45

这取决于您的妄想水平。由于SSD会处理写入数据的方式,因此在SSD上执行一次零写入不如在硬盘上执行一次。

当您在HD上写入特定的数据页时,新数据将被简单地覆盖在旧数据上,以替换旧数据。在整个磁盘上写入零,所有旧数据都将消失。另一方面,SSD无法简单地覆盖各个页面。为了替换页面上的数据,必须首先擦除旧数据,并且SSD无法擦除单个页面;他们必须擦除包含许多页面的整个块。

因此,当您要求SSD覆盖第5页时,会发生以下情况:SSD独自保留第5页上的数据,但将其标记为无效,分配另一个当前空白的页面(例如,#2305),写入将新数据添加到页面#2305,并记下操作系统下次要求页面#5时应改为#2305。原始的第5页数据一直存放在那里,直到稍后,当驱动器需要更多空间时,将所有剩余的有效页移出该块,然后将其擦除。SSD的物理内存容量超过了暴露给计算机的物理内存容量,因此它们可以在需要擦除任何东西之前先弄一下这样的块(并且当它们实际上擦除了某些东西时,没有很好的方法来预测剩余数据的哪些块将被擦除)。选择删除)。查看此AnandTech评论 以获得更多详细信息(警告:它相当长,并且相关内容四处传播)。

最终结果:如果您在“整个”驱动器上写入零,则实际上并没有覆盖所有旧数据。您已经更新了控制器的转换表,因此它将永远不会将任何旧数据返回到操作系统(这些页面都是无效的)。但是,如果某人的核心能力足以绕过控制器,那么他们可以取回您的一些数据。

覆盖两次可能会起作用,但这取决于控制器的分配策略。使用随机数据(diskutil randomDisk 2 /dev/diskN)覆盖两次的可能性更高,但仍不能保证。这两种方法都有一些不良的副作用:它们会占用驱动器的某些使用寿命,并且还会增加SSD上的逻辑碎片,从而降低其写入性能。

请注意,OS X的图形磁盘实用程序的最新版本禁用了SSD上的安全擦除选项(出于上述原因),但是命令行版本仍允许它们。顺便说一句,我还看到了一些建议,可以通过将SSD转换为加密格式来安全擦除SSD,但这(如果有的话)比用随机数据覆盖安全性稍差。

安全擦除SSD的最佳方法是调用控制器的内置安全擦除功能。这应该(如果控制器设计者做了他们的工作)真正擦除所有块,并且还具有重置逻辑页面映射,实质上对其进行碎片整理和恢复其原始性能的副作用。不幸的是,我见过的大多数实用程序(例如CMRR的HDDErase)都在DOS下运行,而DOS无法在Mac上启动。我确实在微件上发现了一个带有(相当复杂的)指令的帖子,用于从GParted引导CD进行安全擦除。也可以从可引导的闪存驱动器中使用Parted Magic,但是我还没有尝试过。

UCSD非易失性系统实验室的研究人员已经通过“擦除”驱动器,然后拆卸驱动器以绕开控制器并检查剩余数据(摘要全文),测试了多种消毒SSD的方法。他们的结果大体上与我上面所说的相符(并且还表明内置的secure-erase命令并非总是正确实现):

我们的结果得出三个结论:首先,内置命令是有效的,但是制造商有时会错误地实施它们。其次,通常两次(但并非总是如此)覆盖SSD的整个可见地址空间就足以清理驱动器。第三,用于单个文件清理的现有面向硬盘的技术都无法在SSD上有效。


1
感谢您的广泛回答。对您来说,运行Terminal命令对我来说不是问题。但是,以供将来参考:不太熟悉Terminal的普通用户可以做什么?只需使用Disk Utility的7次通过选项?
Rinzwind

4
我不知道我现在是否真的可以“推荐”任何选项,它们都有些烂。任何覆盖选项都将耗尽驱动器的使用寿命,并且会增加碎片并降低性能。对于苹果而言,最好的办法是在磁盘实用程序中添加ATA安全擦除(即基于控制器的选项)作为选项,但是谁知道何时/是否会发生这种情况。
戈登·戴维森

2
@Gordon-那是一个很好的信息!+1
Dolan Antenucci

嗨@GordonDavisson。自从您写完此答案以来,是否有任何变化感到好奇(此后已进行了一些操作系统更新)。
samthebrand,2014年

@SamtheBrand:变化不大。我添加了一条注释,即“磁盘工具”(GUI版本)现在不允许对SSD进行安全擦除(因为它实际上无法工作),修复了HDDErase的链接,并添加了一条注释,“ Parted Magic”可能有效(尽管我没有尝试过) )。
Gordon Davisson

8

打开一个终端并输入以下命令:

df -k

请注意与您要不可逆删除的SSD分区相对应的第一列。可以说是/dev/disk1s2

键入以下命令:

dd if=/dev/zero of=/dev/rdisk1s2 bs=100k

/dev/rdisk1s2与您的SSD上的分区关联的原始设备在哪里。该命令将从第一个块到最后一个块完全写入该分区。该命令将持续很长时间(〜1/2 h,共100 GB),并且没有良好的滚动进度条。

此命令返回后,会提示您外壳已完全且不可逆地擦除了磁盘。启动Disk Utility并检查该分区。它会告诉您它已损坏,无法进行任何形式的维修。是的。

只需格式化此分区即可。

这是在物理块级别发生的事情:dd和DU的电影擦除SSD


1
这等效于Disk Utility的选项以零覆盖,并且出于相同的原因在SSD上也不是完全安全的。请参阅我的答案以获取详细说明。
Gordon Davisson

→戈登:我读了你的答案,我想我理解了,我为此答谢了它的质量。我的答案是使用原始磁盘设备,而不是第一个磁盘块(作为“磁盘工具”)。必须在SSD(使用可信赖的工具)上对此进行验证,但据我所知,在使用缓存的旧标准HD上,原始磁盘接口是避免此缓存的简便方法。SSD设备只是一个HD磁盘,其中的高速缓存为满容量,并且已删除了物理磁盘。
2013年

使用原始设备(/ dev / rdisk *)绕过OS缓存,但不绕过闪存转换层(这是我描述的问题的根源)。实际上,没有办法从操作系统中绕过它-设备控制器永远不会将真正的原始闪存存储暴露给总线(SATA或其他任何东西),并且由于操作系统只能通过总线与驱动器进行交互,因此没有它获得原始访问权限以进行安全覆盖的方法。
Gordon Davisson

这里的第一步dd不仅是绕过某些缓存级别(我们没有任何办法知道它们的容量),而是部分耗尽它们(这是图3的状态)。第二遍确实必须找到新的块并安全地擦除它们。
2014年

这还不够,有两个原因:首先,当“磁盘工具”格式化磁盘时,它只会覆盖磁盘的一点点(分区表,卷标头等),并且不能保证足以耗尽额外的容量。其次,根本无法保证与dd擦除之前相比,额外的DU写入会遇到不同的物理块-根据控制器的分配策略,完全有可能一遍又一遍地擦除相同的物理块。这就是为什么我说,即使两次覆盖所有空间也可能不够。
Gordon Davisson 2014年

7

SSD的“磁盘工具”中的“安全选项...”按钮当前显示为灰色。根据http://support.apple.com/kb/HT3680,正常擦除SSD可能足够安全:

注意:对于OS X Lion和SSD驱动器,“磁盘实用程序”中不提供安全擦除和擦除可用空间。SSD驱动器不需要这些选项,因为标准擦除使其很难从SSD恢复数据。为了提高安全性,请考虑在开始使用SSD驱动器时打开FileVault 2加密。

仍然可以diskutil secureErase freespace 4 disk0s2在恢复分区的终端上运行类似的操作。

不过,在擦除驱动器之前仅打开FileVault 2可能是一个更好的选择。根据此答案,如果启用了FileVault 2,则执行远程擦除也只会擦除加密密钥:

是的,当您远程擦除计算机时,它会进行安全擦除。苹果甚至警告您可能要花费一天的时间。但是,如果您的驱动器已使用FileVault 2加密,则无需擦除磁盘。安全地擦除磁盘上存储的加密密钥就足够了,这就是它们的作用。它与基础加密系统一样非常快速且安全,目前该系统非常安全。

http://training.apple.com/pdf/wp_osx_security.pdf

FileVault 2使IT部门能够随时从给定的Mac删除加密密钥,以确保用户登录或数据恢复工具无法访问加密的数据。此过程称为远程擦除。


5
存储敏感数据之前打开加密(即FileVault)是一个很好的选择,但是我发现用于“擦除”加密密钥的过程可能并不完全安全,原因与标准安全擦除不一样的原因相同- -旧的加密密钥仍将存储在闪存中,仅存储在映射的页面中。因此,可以绕过控制器的人仍然可以使用“擦除”键...
Gordon Davisson 2013年

@GordonDavisson,但是如果您随后在格式化驱动器时再次启用加密,则旧的加密密钥应该被覆盖,因此不能安全地访问旧的数据吗?
超大

@supersize旧的加密密钥可能会被覆盖,但是它完全取决于重新格式化期间要擦除的物理页面,而这是驱动器固件控制的,而不是操作系统的控制。
Gordon Davisson
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.