Full Disk Encryption For Macbook?

Discussion in 'other security issues & news' started by x942, Feb 22, 2011.

Thread Status:
Not open for further replies.
  1. x942

    x942 Guest

    I am about to buy a macbook pro 13 inch for iOS development. However I cannot find any thing about encrypting the HDD besides PGP (Which costs ALOT). I am looking for something like truecrypt and haven't had any luck yet. Does anyone know of a free solution for this on Mac OS X? To be honest its not a huge deal as I can always install windows using bootcamp and Encrypt that for banking and stuff. I just prefer to keep an encrypted HDD incase my laptop gets stolen that way the theif won't have anything valuable besides the laptop itself. All my personal bank and credit card info will be safe still. :)

    Thanks for any help!

    Sorry if this is the wrong Section I wasn't sure where to put it.
     
  2. katio

    katio Guest

  3. x942

    x942 Guest

  4. katio

    katio Guest

    Sorry, I don't know for sure. It's worth a try I guess.
     
  5. katio

    katio Guest

    Update: 10.7 Lion finally brings FDE to OS X.
    It's XTS-AES 128 only, a bit of a weak choice in my view.
     
  6. x942

    x942 Guest

    Sweet but ya I use 256-bit in XTS mode. 128 bit in XTS is strong but no were near as strong. I will stick with PGP or just encrypting the Win 7 partition until something better comes along. Thanks for the tips! I may enable just for the hell of it too. Some protection is better than none and I doubt any one besides someone with a supercomputer could crack 128-bit anyways.
     
  7. chronomatic

    chronomatic Registered Member

    Joined:
    Apr 9, 2009
    Posts:
    1,343
    Meh, unless you're hiding out from NSA, it won't be breakable by anyone (and it's doubtful even then). Much more important is the user, his passphrase, his physical security of the system, etc.
     
  8. katio

    katio Guest

    The point of disk encryption is to secure data at rest. That usually implies a longer period of time.
    The overhead of using 256 over 128 bit is absolutely not worth even talking about. Everyone using FDE already accepted a drop in performance.

    I simply can't understand why Apple didn't went with a more future proof option that would have costed them nothing. That's all.
     
  9. x942

    x942 Guest

    True enough I am just use to 256-bit so I kind of wish that's what they put in but with another one of my randomly generated 64 Character ASCII passwords I doubt anyone will break it anytime soon :p The only other worry I have is it will have a "recovery" option like windows bit locker. If there is a recovery option it should be done like truecrypt which is actually secure unlike bitlocker's recovery pin system which I believe has been cracked.

    EDIT: For those who don't know truecrypt creates a recovery disk that allows you to fix the MBR, put the encryption key back from a backup (thats securely hashed with your password) and perform and emergence decrypt (provided you have the password).
     
  10. chronomatic

    chronomatic Registered Member

    Joined:
    Apr 9, 2009
    Posts:
    1,343
    Likely never. The only way would be social engineering, keyloggers, or TEMPEST. But if an enemy is going that far, you have probably already lost the battle.

    I can't speak for what it does or doesn't have as I have no knowledge of it whatsoever other than what I've seen in this thread. If I used a Mac, I would rather harass the Truecrypt devs to get on the ball with an OS X WDE implementation. I would rather trust an open-source implementation from a third party not associated with Apple. But that's just me.

    On a side note, AES-128 might actually be more secure than AES-256. I know this seems paradoxical but there have been attacks on all 14 rounds of AES-256 that are faster than brute-force, while there are no known attacks on AES-128 that are faster than brute-force.
     
  11. x942

    x942 Guest

    I agree TC needs to move over to Linux and Mac OS X it is far more powerful. as for Tempest and and EvilMaid and Cold boot attacks these are useless in real life for a multitude of reasons. The first two are stopped cold by proper security and an AV or AM program. (My system is hardened even further with SRP and other tweaks to prevent 99% of all attacks). Evil made again is stopped if I choose to run the TC bootloader of an SD card/usb stick instead of MBR. Cold boot only works in lab conditions so thats also out the window as RAM degrades in a matter of seconds (Provided they aren't me and don't have a script set to wipe RAM on shutdown :D). also Bios locks and HDD Locks negate these attacks as well.

    The 128 bit argument is valid however if you take into account that even with those faster methods it is still infeasible to crack AES-256 bit than it doesn't really matter. Another thing is to use a Cascade like I do on my 1TB external HDD that will not be broken even if AES is as each key is independent. My laptop is AES only as all sensitive data (Clients data and such) is stored on the HDD).

    Thanks for the help though :D
     
  12. katio

    katio Guest

    I disagree.
    Against the first two software based solutions are next to useless.
    There was a project that mitigates both but it's very tongue in cheek and I doubt anyone was using it for day to day activity: http://tinfoilhat.shmoo.com/

    TEMPEST by definition is a hardware problem that requires physical access. Therefore the obvious answer is physical security. Similar goes for EvilMaid. It is software of course but since it runs before the OS kernel OS level security systems, by definition, are not to be trusted.

    Where I agree is that based on the assumed threat level this is the least of your worries.
     
  13. x942

    x942 Guest

    If I remember correctly Tempest is installed via windows OS so and AV would stop it. As for EvilMaid PrevX scans my MBR not to mention an attacker would need to bypass my HDD lock/BIOS password,or boot removable media/put HDD in other pc. Easily stopped in two ways: Scan MBR when doing regular virus scans and enable BIOS passwords. The second way is to wipe the TC MBR and place the recovery disk on a bootable SD Card/USB drive and thus Evil Maid is useless once again. Cold Boot attack only works in IDEAL LAB conditions and is not practical IRL. To be honest if my laptop went missing I would just wipe the drive and reinstall all my data is on my encrypted 1 TB External HDD. I only worry about browsing/banking data on my laptop which is why I use FDE. Also chances are any thief would wipe/install windows and sell the laptop.
     
  14. chronomatic

    chronomatic Registered Member

    Joined:
    Apr 9, 2009
    Posts:
    1,343
    Uh, no. TEMPEST is not software.

    Which is simple for an attacker to do.

    Scanning MBR may or may not work, and a BIOS password is not a deterrent whatsoever. Anyone with physical access to your machine can bypass a BIOS password in a minute or two. Moreover, if they have physical access to your machine, they can simply flash the BIOS itself with a new "infected" BIOS.

    Putting the MBR on a removable disk (USB) would stop any tampering there, but there's still a problem with the BIOS and other flash ROM's on the board.

    It doesn't take a lab. All it takes is some malcode and a little time.

    The only way to ensure you don't become a victim of the Evil Maid or Cold Boot attacks is to make sure no one ever has physical access to your machine but you. This means if you have to leave it somewhere for any decent period of time, it should be locked up securely. I read somewhere (it might have been on these forums) that a guy had a wire hooked to the door of his computer room. When the door opened, the wire shut off all power to the machine. This would help stop a Cold Boot attack, but it wouldn't do much for Evil Maid or a hardware keylogger. Besides, this tripwire scheme probably wouldn't work against sophisticated people (unless the tripwire was deviously engineered and hidden well). A much easier way to defend against the Cold Boot attack is just to turn the machine off when it's not in use (but I realize this isn't practical for some people). The only way to stop Evil Maid or hardware keyloggers is to make sure no one ever has physical access when you're not around.
     
  15. x942

    x942 Guest

    Tempest: you are right i was confusing it with the bootkit. Still not to worried.
    Evilmaid: Scanning works perfectly take a hash of you MBR and check i before boot. Doesn't match? Use the recovery disk to put it back. Also when i say moving the mbr to an external source i mine there is no boot loader on the hdd for the attacker to see or modify. If I suddenly turn it on and there is one i will be questioning that and wipe the entire hdd. As for cold boot: it does only work in a lab in ideal conditions. After 30 seconds memory degrades making such attacks useless as it takes more than 30 seconds to remove ram, bypass bios passwords/locks. Not to mention my computer wipes RAM on shutdown so its DOA.

    BIOS locks on laptops are more secure than computers and will greatly slow down an attacker to the point making Cold Boot useless. Don't believe me? Try any exsisting bios cracking tool - they don't work. Laptops tend to also not be susceptible to battery removal tricks as they retain the information still. HDD locks are also more difficult. Please realise i never said they were 100% but they add protection and prevent coldboot because it would require either more than 30 seconds to bypass and the loading of such a tool would over right RAM.

    On a side note: the two other flaws with all of the above:

    1) As mentioned above if my laptop went missing i would simply wipe the HDD if i go it back with DBAN.

    2) I am not running from the government or any one who would go through this much trouble just to access my computer. Like mentioned before all my real private data is on my 1 TB HDD at home encrypted with a cascade and 64+ char. Randomly generated password and several key files. Since you cannot differentiate encrypted data from random data there is no way of knowing or proving it is encrypted.
     
Loading...
Thread Status:
Not open for further replies.