Article Preview
TopPrevious Work
Ideally, a forensics investigator would have a back-door to any cryptography that they might encounter. Such mechanisms have long been proposed (Denning & Branstad, 1996), but have not seen widespread adoption. Occasionally there are mistakes in the implementation of cryptography that have lead to weaknesses (e.g. a software bug caused predictable keys in the Debian OpenSSL package, Bello, 2008), but the number of cases is small, and one cannot rely on them being present.
In spite of the obstacles, a good deal of research has been undertaken on what options are available to a forensics investigator in the face of encrypted evidence. The majority of the work to date has focused on capturing keys from live memory. Shamir and Someren (1999) proposed a method for detecting high entropy as a tell-tale aspect of RSA keys. Klein (2006) instead looked for the common formats and syntax of keys and certificates. Halderman et al. (2009) extended the timeframe during which keys in memory could be captured, by freezing the RAM and using error-correction techniques.
The problem addressed by McGrath, Gladyshev, and Carthy (2010) was that of a forensic investigator analysing a suspect's hard-drive where there were concerns about the use of encryption, namely PGP/X.509 or compatible software. The investigator wishes to obtain all cryptographic material and, where possible, determine what was encrypted and to whom it was sent. Access to public key servers is assumed to be available.
Searching for Artefacts
The first step described in the methodology is to search for keys and encrypted files on the suspect's hard-drive. File signatures (fixed byte patterns that always appear at the start of the file) for public key and ciphertext files were determined for various key sizes (512, 1024, and 2048-bit key strengths).