在我的应用程序中,我需要删除包含敏感信息的文件。为此,我正在编写一些由随机字节生成的垃圾,然后使用File.delete()方法删除,如下所示:
long size=file.length();
Random r=new SecureRandom();
OutputStream os=new BufferedOutputStream(new FileOutputStream(file));
while(size > 0)
{
os.write(r.nextInt());
size--;
}
os.close();
file.delete();
所以问题是:这个方法是否保证如果有人取消删除文件,那么只会发现垃圾而不是真实的内容?我不完全确定写入文件会保证下划线Linux文件系统中的相同扇区会被覆盖......请提示 - 做什么 - 确保文件内容被破坏。
答案 0 :(得分:4)
不,它不能保证原始块被覆盖 - 在闪存设备上它们极不可能,尽管可能需要低于O / S级别的工具甚至低于芯片数据表接口级别的工具恢复。
你真的不能保证擦除,除非你的闪存没有板载控制器可以替换块并重复擦除并覆盖它的低级驱动程序,或者你的物理破坏媒体。
如果您正在谈论带有胖文件系统的SD卡,我相信基于过去恢复意外保存的背面图片编辑,linux甚至不会尝试写回文件系统的相同块。
您可以通过将卡放入Linux机箱并将原始设备文件格式化为已知的已删除文件中的内容来确认数据是否仍可恢复;遗憾的是,这并不能证明数据可能仍然存在于由设备驱动程序或片上控制器重新映射的块中,并且可能由较低级别的工具访问。
答案 1 :(得分:4)
不,它不能保证。原因在于下面的文件系统实现 - 任何标准都不强迫覆盖现有数据。一个完全有效的,(POSIX-)符合标准的实现文件系统写操作的方法是分配一个全新的存储块,将你的“新”数据放入那里,然后改变文件的块结构。一种方式,为您在文件中写入的位置引用新数据块,并且“释放”先前使用的数据块 - 无论具体是什么意思。之后,您无法再访问旧数据(通过文件系统),但它仍然在磁盘上,因此请保存擦除整个存储介质,而不是删除跟踪。
快照或复制等功能的许多文件系统实现都依赖于此机制(Copy-On-Write)。 Linux Btrfs或Solaris ZFS广泛使用它。我认为Android的YAFFS也是如此。正如克里斯所提到的,任何闪存中的磨损均衡FTL也会表现得那样。
通常给出如何在使用copy-on-write的文件系统上处理这个问题的答案是永远不会让它首先发生。即写入时加密文件,删除文件时“丢掉密钥”。你无法解密的东西无法恢复...但我同意鸡蛋问题在哪里/如何存储加密密钥。