alias sleepsafe='sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25'
alias sleepfast='sudo pmset -a hibernatemode 0'
alias sleepdefault='sudo pmset -a hibernatemode 3'
Whenever I travel or need to leave my laptop, I always run `sleepsafe`, which will delete the key from memory and hibernate the computer when I close the lid. It has the added benefit of saving battery life.
Day-to-day, I use `sleepfast`, which is faster than the default hybrid sleep, because it doesn't spend time copying the contents of memory to disk.
I very rarely switch to `sleepdefault` which is the insecure and slower hybrid sleep.
If the laptop is disconnected from AC, it hibernates. It will switch to hibernate if power is removed while already sleeping. If I want to force a hibernate manually, I just pull the power before closing the lid.
Things like this are a reason I unhesitatingly recommend that people stick with their OS's built in FDE:
1. FDE is extremely limited. This particular attack is a clever abuse of sleep/reboot cycles, but of course people intimately familiar with FDE know that if a laptop is sleeping but not shut down it's already perilously close to the boundary at which FDE breaks down. And, of course, once it's woken up and unlocked --- which every attacker who actually challenges FDE can arrange for, all bets are off.
2. When flaws like this are found, the OS vendors have much more recourse than third parties do, which is why this post concludes by saying that Macs are now the most secure laptop platform with respect to DMA attacks against FDE.
Use FDE! Enable it on all your machines! But try not to rely on it, and don't waste too much time optimizing it.
I don't know about Apple but Microsoft has a pretty nasty way of handling user's Bitlocker keys.
If you use a Microsoft account, your key is automatically backed-up in Microsoft's cloud. Red flag #1.
Also, as the recent Bitlocker bypass "bug" showed us, Microsoft has some way of bypassing Bitlocker encryption when it performs updates on the system. I don't know if they have some kind of key escrow or what, but either way - red flag #2.
Of course, I'd say the bigger problem is that Microsoft doesn't even give the majority of Windows users the option to encrypt their computers, by restricting Bitlocker to expensive computers and Windows licenses, while every other operating system does. So the advice to "just use the built-in FDE" doesn't work for the majority of Windows users.
It is possible to suspend Bitlocker. This works by writing the key somewhere on the disk. Then when you reenable it the key is removed again. This is necessary if you normally store the key in the TPM chip and you're going to do something that will break its trust, like updating the BIOS.
The recent update would suspend Bitlocker during the installation which is not a nice thing to do automatically.
Right-o about using the built in FDE. It's kind of funny to think about how many lay users walk around thinking their laptop is safely protected by a password.
My girlfriend was shocked at how easily I was able to "hack" her laptop and reset the forgotten password by changing whatever accessibility.exe to cmd.exe.
This is not really relevant to the discussion, or even fully accurate. Most people who buy windows licenses (including me) buy one of the base licenses because we generally don't need the other "professional" features on our home computers.
> And, of course, once it's woken up and unlocked --- which every attacker who actually challenges FDE can arrange for, all bets are off.
I'm not sure what you mean by that? Do you mean that the attacker can force you to wake up and unlock the computer? In that case FDE is not moot anyway, no?
For me, the reason I use FDE is in the case I lose or forget my computer somewhere, I do not want the legal liabilities with a thief accessing my customer's source code.
Assume that there are generally two kinds of physical attackers:
* Casual, opportunistic attackers who will steal any available laptop.
* Targeted attackers who want your laptop in particular.
Against a casual attacker, even if your laptop is stolen unlocked, it's not going to be carefully kept unlocked. Doing so requires sophistication, care, and extra risk. Instead, the laptop is just going to get wiped.
Against a targeted attacker, like the FBI when they took down Ross Ulbricht (who FDE'd his laptop), the attacker will simply wait until the laptop is unlocked.
I was curious about that, so I looked it up. Pretty interesting stuff.
[0] "On the afternoon of October 1, 2013, officers watched as Ulbricht entered the library and made his way up the stairs to work by the window at a desk in the science fiction section, Kiernan recalled. Meanwhile, sitting on a bench outside of the library, homeland security officer Jared Der-Yeghiayan — who had been working undercover as Silk Road employee "cirrus" — initiated a chat with Ulbricht, requesting that he log in to Silk Road's back end to fix a technical problem. As soon as Der-Yeghiayan could confirm that Ulbricht was logged into the site, FBI agents entered the library.
Two plainclothes FBI agents, one male and one female, walked up behind Ulbricht and began arguing loudly. This staged lovers' tiff caught Ulbricht's attention long enough to distract him from his laptop. As soon as Ulbricht looked up, the male agent reached down and slid the computer over to his female colleague, who quickly snatched it up and handed it over to Kiernan for further investigation."
There was a similar, bar less dramatic, case in the UK recently - where police swiped the phone from the hands of a suspect as he took a call, and then kept interacting with the screen to keep it unlocked long enough to recover the evidence required.
In retrospect, it's a pretty obvious attack vector.
See, this is the problem with people's conception of FDE. This is actually a very silly solution to the problem.
The right approach is to recognize what FDE is good at (minimizing the risk that casual thieves will get data in addition to valuable parts, and protecting computers that can frequently be powered all the way off from even advanced attackers), and then use something better to protect sensitive data.
https://github.com/hephaest0s/usbkill
Checks for changes with USB drives and shuts down the computer and optionally deletes files and wipes ram. USB stick on a wristband > unplugs when they take the computer > shuts down
>the attacker will simply wait until the laptop is unlocked.
A potential counter measure is for the machine to periodically encrypt itself again and prevent use until a password/key is supplied ("clamming up"). This would prevent an attacker who snatched a logged-into computer from having unbounded carte blanche access to the machine. I'm envisioning something that every 10 minutes locks itself.
Even though the computer may be “locked”, if the OS is running and accessing the disk, it means that the key is present somewhere in memory. There are various methods of accessing this key, the fallback brute-force method being the (https://en.wikipedia.org/wiki/Cold_boot_attack). The method from the article only removes the need to physically remove and cool the memory chips.
Macs still have memory chips, even if they are not removable. This can be attacked by using specialized hardware which you press onto the RAM chips’ connectors. The inability to remove RAM is not meant as a security feature, and therefore gives no significant protection against a motivated attacker with specialized hardware.
Ok, I thought that Apple would scrub all keys from memory when the computer goes to sleep so that a computer that's asleep would not be vulnerable to the Cold Boot Attack. Seems strange they don't do that? Or would it make waking up too slow?
Apple wants the computer to be able to wake up on its own in order to fetch new emails and such. Just a few minutes ago, I used Screen Sharing to connect to my sleeping MacBook from another room to check for updates based on this article's recommendation. Quite convenient, but it does imply that the OS keeps the keys around.
I'd bet that if you turn all that stuff off, they keys are scrubbed. That could be a good compromise instead of turning the computer completely off all the time.
> Do you mean that the attacker can force you to wake up and unlock the computer? In that case FDE is not moot anyway, no?
The Windows lockscreen has had a law enforcement backdoor since at least Windows XP. This effectively makes FDE worthless on Windows if you only put your computer to sleep instead of a full shutdown.
Good on Apple for "completely" fixing this, according to the authors. But am I wrong to wish for more plain-English acknowledgement of the problem and reassurance in Apple's 10.12.2 release notes?
Anyways, at this point in time it's nice to read (from the authors of the exploit): "The mac is now one of the most secure platforms with regards to this specific attack vector."
I read through the release notes, and I didn't see any mention of this issue at all. The fix must have been a EFI firmware update (my Mac did restart multiple times during the update, so this sounds plausible), but nothing is mentioned about this anywhere.
I saw the firmware-update progress bar (one of several similar progress bars that macOS/OS X can show during startup) during a 10.12.2 update. So that's a bit more confirmation...
But what worries me somewhat is that the tools for mitigation for these families of attacks include a lot of technologies that are traditionally opposed by the community here on the grounds that it "takes away control from the user.
I'm not sure how we balance out those tensions, but attacks like this sure as heck concern me about my homebuilt machine. I do my best not to keep any important keys there.
Is the update an EFI update which disables DMA or does it with IOMMU? Or is the memory just overwritten on boot?
I'm also quite surprised they leave the password in memory in multiple locations. - Assuming the password is only used to derive the KEK for the actual key.
This interests me, too. I can only assume, since disabling DMA would imply a huge performance hit (and quite likely many broken devices?), that the update enables the IOMMU right from the system start, probably directly in the firmware, and has nothing/only a whitelist mapped, with further mappings only explicitly enabled by drivers?
I wonder if the chipset can't do a sort of DMA emulation, or DMA with conditions versus the sort of free-for-all stuff you'd see with things like FireWire.
Without an IOMMU devices on extension buses directly address physical memory.
With an MMU the host CPU creates a virtual address space for devices and can thus limit access to the main memory (conveniently also allows passing devices to VM guests), much like virtual memory for processes/VMs.
I'm still using it instead of Sierra because of Karabiner but this could force me to upgrade.
That vulnerability seems to be a pretty obvious oversight. I remember hearing about DMA (in the context of Firewire) as an attack vector since people first started talking of Truecrypt and Filevault and scrubbing the memory seems obvious... It's worrying that this could have been overlooked by Apple's engineers.
I haven't tried it because I can't find the wireless mouse that I needed Karabiner for, but my impression was it has most of the functionality running, especially the key/button remapping which seems to be their biggest use case.
I haven't found a way to configure Karabiner Elements to replace Caps lock with Escape when I only press that key (for vim) and with Ctrl when I press it in combination with other keys (for the terminal).
I also have both Shift keys bound to () when pressed alone and Shift when pressed in combination with other keys.
That changelog includes a bunch of fixes that are Sierra only, so the answer may be "no" contrary to your comment.
This is the closest I can find on there to this issue and the fix is Sierra only:
IOFireWireFamily
Available for: macOS Sierra 10.12.1
Impact: A local attacker may be able to read kernel memory
Description: A memory corruption issue was addressed through improved memory handling.
CVE-2016-7608: Brandon Azad
Attribution on that doesn;t look right; TFA was by "Ulf Frisk" who was nowhere on that page.
Why would someone be using El Capitan still, some may ask. Well there is software not updated for Sierra yet. For example, GPG for Mac is not yet ported over.
Well, I'd say "Turning off your device is the only protection when you have FDE", since shutting off your computer will do nothing to protect it if you don't have FDE enabled.
If it's not encrypted, connecting another computer to it with an appropriate cable will let you use it as a remote disk, leaving no real traces that it was touched.
Uhh, I think that was pretty clear from my comment. FDE only gives you "complete" security in transit if you shut it off. Leaving a FDE computer in sleep mode will not protect you.
But even in sleep mode, a FDE computer is still better than no encryption at all.
Are you planning to backport the fix? It would be very disappointing if a serious security problem like this would be left unaddressed. Not all of us can or want to switch to the latest major within months after its release.
While I'm not excusing this bug (didn't they already go through this round of DMA bugs with FireWire?), this reinforces my belief that once you have physical access to a personal computer - all bets are off. If you lost your laptop, rotate all keys. Change all passwords. Assume everything is compromised.
There is a huge difference between physical access and the computer being on. That is the first thing this exploit says -- it doesn't work if the computer was turned off previously.
This has always been the way to protect a computer that uses full disk encryption. Turn it off. Sleep mode will not protect you.
The kernel version was incremented due to kernel fixes (https://support.apple.com/en-us/HT207423). The Filevault vulnerability was fixed in 10.12.2 with a firmware update, part of the incremental update.
Day-to-day, I use `sleepfast`, which is faster than the default hybrid sleep, because it doesn't spend time copying the contents of memory to disk.
I very rarely switch to `sleepdefault` which is the insecure and slower hybrid sleep.
This has been a known issue for years http://osxdaily.com/2013/07/06/maximize-filevault-security-d... https://nakedsecurity.sophos.com/2012/02/02/filevault-encryp...