RE: Handling, possibly, encrypted data

From: Erick Arturo Perez Huemer (eperezat_private)
Date: Mon Aug 19 2002 - 02:34:50 PDT

  • Next message: Vladimir Kraljevic: "Re: Sniffing From Windows 2000..."

    My point of view:
    Several encryption applications (file level or disk level) have know
    headers to look for (example PGP) while this is good for a forensic
    reviewer it is not good for people trying to hide/protect data from
    curious eyes.
    
    Some companies have tried a different approach and they are not placing
    any (not to my knowledge) know headers in the encrypted
    file/volume/disk. One good example of this is scramdisk
    (http://www.scramdisk.clara.net) that know calls it BestCrypt. Scramdisk
    do not place headers in files so you are supposed not to be able to
    recognize them by checking headers. This will of course make the
    forensic job a much harder task (while this is bad news...isnīt that the
    whole idea of encryption?).
    
    Having this in mind I can think of this ways to check for encrypted data
    (but Im not a cryptographer!!)
    
    A- first try to determine if you are checking images or data.
    A.1 if you are checking for images, there are several programs that do
    not read the headers (thus avoiding the possibility that the owner
    deleted them) but try to read the file directly instead. If they are
    able to decode the file to a known format, they will show you the image.
    A.2 If you're checking for data, check headers (there might be a few
    data-viewers that also do not read the headers but try to read the
    file....any Encase users around?)
    B- check for compression levels. Data and image files can be compressed
    *way* more than an encrypted file (good algorithms do compression before
    encryption).
    C- [expensive and time consuming theory] While smoking the last cigar in
    my package....Encrypt known blocks of data with different algorithms
    (popular ones?), check sizes, check compression levels, you might find
    something there.
    Maybe the NSA do something like this in pattern analysis systems....
    (randomness levels, encryption ratio, does the transmission contain
    *words*..etc)
    D- Remember that encrypted data should be random at maximum levels.
    Viewing hex dumpings should reveal nothing vaulable to a machine or to a
    human eye.
    F- *some* crypto apps like to add extensions to protected files or
    volumes. While this can be easily removed..check for deleted files with
    known cryto extensions (maybe the user was sloppy and forgot to run the
    wipe program).
    G- Stop looking for an app that can tell you if a file is encrypted. I
    think that *kind* of app (if exists) will never be available to
    non-extremely-classified community.
    H- If you can succesfully map doc,xls,etc files. Check them..dont be
    fooled. I often encrypt with my pgp tool and then save the encrypted
    text inside a MS Word .DOC file with a very obvious name (Maddonna's
    best song.doc) I'm sure it will defeat forensic newbies who only look
    the name but not all the data. Well, itīs nice for me (dont ask why).
    I- If someone is trying real hard to hide information using crypto
    tools, then they will not use programs that place known headers on the
    encrypted files. At least that's what i would do if I ever move to the
    dark side of the force.
    
    If someone ever devices a way to correctly let you map and encrypted
    file (and you survive the feds) the post it to the list!! (no pun
    intended).
    
    Bye,
    
    Erick
    PGP ID: 0xF4FAF330
    PGP Fingerprint: 3B75 C625 03CD 5304 3266
                     D3A2 AFEC C89B F4FA F330 
    
    
    
    -----------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see: http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Mon Aug 19 2002 - 03:18:19 PDT