As you learned in Chapter 4, the iOS operating system is inadvertently working against your application’s security by caching data in precarious places. Apple prides itself in style, but to deliver superior application integration, certain concessions are made to improve performance and provide the seamless experience for which Apple is known and loved in the consumer market. In this chapter, you’ll learn some techniques to help protect the data in your application from being leaked to other parts of the filesystem as a result of these integrated features, or for other reasons.
Forensic examiners love it when a suspect deletes data from his application. Not only does it present an opportunity to show off their elite skills mastering file un-deletion, but is also compelling evidence of guilt when data is recovered. Many users—even power users—still think that files are permanently deleted when the trash is emptied on their desktop. Apple has made great progress in protecting the unallocated space of a filesystem, but there are still some common flaws in its implementation that stand to expose the data in your application.
As you learned in Chapter 4, the HFS journal writes a
cache of changes to the filesystem, so when content is written or
encrypted, the keys are copied into this journal. While Apple seems to be
doing a good job at destroying the
cprotect attribute containing a file’s encryption key upon deletion, the HFS journal operates ...