8 ms·
Secure Boot and the 2018 MacBook Pro
- userbinator 8y agoSummed up in one word: Scary. Maybe Apple users are not as concerned about being able to run other OSs, but there was a huge uproar a few years ago when secure boot was first introduced to PCs. Fortunately you can still turn it off, but its removal may be associated with an ostensibly compelling argument: "why would you not want security?" The answer to that can also be summed up in one word: freedom.
- noja 8y agoI don't know why you are being downvoted: losing the ability to install what we want on our computers is clearly A Bad Thing.
- akvadrako 8y agoThis is not that - you can still turn it off and boot whatever OS you want.
- sanlyx 8y agoAnd so can anyone with physical access to the device. I know there's no way to fully prevent evil maid attacks, but Secure Boot helps in that no one can simply plug e.g. a Linux Live USB and wipe my disks in less than 3 minutes
- Klathmon 8y agoDon't most bios have a password protect option? That alone makes evil maid attacks significantly harder.
- sanlyx 8y agoThat's the way to go I guess. But secure boot has obvious advantages in comparison. As a rule of thumb I do not trust any client-side "authentication" or passphrase input as long as there's no crypto involved. In legacy BIOS this passphrase can be bypassed easily, for instance
- Klathmon 8y agoYes, but it's not either-or, both can be used. Combined with a TPU that wipes keys when secure boot is enabled/disabled gives a pretty secure system, that still allows you to "eject" to an unsigned boot when needed.
- zzzcpan 8y agoBooting into linux from usb and wiping your disk in 3 minutes is not a real threat. It's not even a hypothetical threat. Why not just steal the thing instead or physically destroy it if you want to wipe the disk for some reason? And what reason would that even be, why would anyone want to wipe the disk given physical access? As losing data is something we already expect from mere hardware failures, software failures, operational mistakes, etc., no attackers necessary. So, no, the whole secure boot thing is just bullshit security theater and more lock in.
- _jal 8y agoDigression alert: I'm not talking about MBP-related stuff at all. > So, no, the whole secure boot thing is just bullshit security theater and more lock in. Only if you're only thinking about laptops, desktops, maybe phones and tablets. There are lots of types of machines out there physically exposed to users whom the machine-owners trust to varying degrees, ranging from "not at all" on up. Think UPS package scanners, HVAC systems, various control systems in everything from warehouses to prisons, sensors and signage controls... Now, Secure Boot doesn't address anywhere near anything close to "sufficient" in any of those environments, but it is one component of raising the costs of attacking them to a point to make the systems economically viable, or at least apparently so.
- 21 8y agoAgainst the evil maid you are supposed to use SecureBoot together with full disk encryption and TPM. If someone disables SecureBoot, then the encryption keys become inaccessible and you will notice that something is wrong. I don't quite understand your wipe the disk thing, since that will leave a trace, the attacker could just smash your computer or take out your drives.
- rocqua 8y agoReally, that should not be possible with secure boot. Secure boot ensures only trusted OSes are run, and those OSes should require authorization before allowing secure boot to be turned off. Scarier evil maid attacks involve changing hardware or firmware. The personalized version of secure boot mentioned would make that more difficult. Incidentally, an interesting defense against evil maid attacks involves glitter nail polish. Use it on a sticker over the case and take a photo. To verify your laptop is safe, compare the sticker with the photo. The key is that glitter polish has a lot of minute detail and is thus hard to replicate. This only gives tamper protection, but evil maid attacks require interaction so it suffices for security.
- saagarjha 8y agoWiping a disk is not a security threat; I can do that from the recovery OS without booting into Linux. What is a security threat is modifying the operating system to contain a backdoor so that it can read from your hard drive when you unwittingly enter your password to unlock the disk.
- epistasis 8y agoI don't understand what either of your comments have to do with the article. You seem to be assuming some counterfactual implementation of the feature, but the article is quite explicit that these fears are unfounded. There is no loss of the ability to install what you want.
- IntelMiner 8y agoIt puts mechanisms in place to deny that in future, however
- craftyguy 8y agoBecause it's not accurate. You can install whatever you want on a system with secure boot.
- sanlyx 8y agoIn most Secure Boot-enabled PCs you can manage keys and certificates on the firmware KEK/DB variables by using utilities such as KeyTool, so that you can safely boot any EFI-compliant OS with a custom certificate. I'm not sure how this would work on Apple devices. It seems to me they have reinvented the whole security infrastructure of their services, which it's not a bad thing, but also requires some serious hacking if you don't want your device locked down with Apple-only software. Is there any way you could possibly manage the trust chain of secure boot on devices with the T2?
- floatboth 8y ago> some serious hacking I guess "Reboot into Recovery, Open the Secure Startup Utility and allow booting from external media and Set it to No Security" counts as serious hacking now :)
- the_why_of_y 8y agoThat simply disables Secure Boot, which is not what sanlyx wants because you don't get the security benefit of replacing the manufacturer provided PK and/or KEK with your own so that only images you signed will boot.
- floatboth 8y agoSure, you don't get your own secure boot, but the point is, it's not "omg apple lockdown no third party OS possible at all"
- shaabanban 8y agoI don't know if this crosses the line into scary for me simply due to the fact that it can be turned off. Based on what I just read nothing would stop me from switching to the "No Security" mode and installing whatever I want.
- userbinator 8y agoBased on what I just read nothing would stop me from switching to the "No Security" mode and installing whatever I want. ...for now. The frog boils very slowly.
- beagle3 8y agoEverything is possible, of course, but Apple makes money from selling hardware, not from selling an OS; They're likely to keep letting you run what you want (which is in their interest so you don't buy hardware from another vendor even if you want to run Windows or Linux) -- although they might condition warranty and service on your computer running a blessed, signed and secure OS/X.
- darpa_escapee 8y agoPeople still buy iPhones and iPads despite the hardware platform lockdown.
- GW150914 8y agoIn many cases they buy it because it’s a walled garden and locked down. When the alternative is Android it’s not hard to see why. People here seem to miss that while some people want freedom to experiment and play, others want the freedom to just have the device work as intended and not have to worry about fraudulent or malicious apps. It would be weird if a dev preferred the lockdown, and weirder still if my grandmother didn’t.
- jsjohnst 8y ago
- craftyguy 8y agoEh. Most (all?) x86 systems with secure boot support loading your own keys for signing/verification. All systems I have that support secure boot are using my own keys to verify the linux kernel before loading it.
- munchbunny 8y agoAs long as secure boot is optional, I think having the ability to use it is a good thing. As an individual, the freedom to install whatever OS you want is important. As a company, you want to have the option to bootstrap the software from a cryptographically signed image so that group policies, etc. can all be enforced in one long, auditable chain starting from the onboard TPM. While most employees might not need that, something like that is useful for making sure remote datacenter access is secure.
- bad_user 8y agoI worked for a big company with an IT department that was forcing strict policies on everybody. E.g. installing Skype could get you fired. But the developers working on projects for that company basically ignored the rules, because it was the only way to get anything done. Not saying that there aren't companies for which this is desirable. Such companies exist. What I am saying is that their reasoning is bullshit and has more to do with some people keeping their jobs, so it's job security instead of actual security.
- munchbunny 8y agoI think we're talking about slightly different things. I'm a proponent of proportional amounts of paranoia. Restricting everyone is disproportional. Preventing developers from installing software on their dev boxes probably does more harm than good. On the other hand, putting tight controls on computers people use for admin access to servers is not a bad idea if your company is big enough that only the dev ops guys really need to be in there with real regularity, or if your company handles sensitive data. Then the practical layer of security might be worthwhile to make getting into the datacenter via a compromised engineer or dev box harder. That's the scenario I'm familiar with: secure boot on a separate machine, and a tight lid on what software you can put on the system, in order to guarantee a baseline level of hygiene for any system that talks directly with the datacenter.
- geofft 8y agoIt is absolutely scary to me that "my" computer could be running some OS that I don't want it to run. I have no freedom if someone else controls my OS. That's why I run free-software operating systems with secure boot enabled.
- frostburg 8y agoAre you aware of the fact that your computer runs a lot of scary code that you can't see anyway? Do you audit the firmware of your drives?
- riquito 8y agoYou don't need to verify everything yourself, when the code is open you can trust one or more third party auditing
- zeusk 8y agoand since when were device firmwares "open" or audited by a "trustworthy" and "competitive" party? I work on OneCore (Windows) and sometimes I have trouble believing the kind of crap some hardware vendors ship as firmware.
- scarface74 8y agoHow did that work out for the HeartBleed bug that was in Open source code for a year?
- geofft 8y agoI am absurdly aware of this. I am also absurdly aware that most free software isn't audited, either, and is full of unintentional security vulnerabilities more exploitable than anything going on with my proprietary firmware. Nonetheless, I believe in incremental improvements. (Note that untrustworthy drive firmware has an easy workaround at least in theory - just do full-disk authenticated encryption, and then the drive can't do anything worse than DoS you, which is sort of a thing drives tend to do on their own anyway.)
- 8y ago
- 0x0 8y agoAs long as the option to use secure booting stays user-configurable (even if it's opt-out), this sounds like a great way to for example do theft deterrent - if you can mark a specific macbook's serial number as stolen, and thus preventing internet recovery or reinstalls from external media, just like you can with iOS devices today via Find My iPhone, where Apple may deny granting a re-installation AP-ticket for the device's serial number, all the better. If word gets out to every shady character that stolen macbooks are effectively bricks, perfect.
- debatem1 8y agoFreedom and secure boot are not mutually exclusive things. The important bit is the ability to enroll your own signing key. See the yellow state in this diagram: https://source.android.com/security/verifiedboot/verified-boot https://source.android.com/security/verifiedboot/verified-bo... Disclaimer: I worked on this.
- amerine 8y agoThanks for the wonderful write-up.
- vondur 8y agoThere is a command you can run that will allow you to boot and do the restore from Apple. But you definitely need a fast internet connection. If you manage Mac’s you are going to have to sign up for DEP and something like JAMF.
- shiburizu 8y agoWhat I don't get is this: If Apple wants to introduce "Secure Boot" while also pitching their products to "creative professionals" (who most surely run to their IT departments to pick up their MacBooks fresh off a purchase order) would they really overlook an imaging solution? Surely being the kings of walled garden ecosystem could spin this up in their own solution.
- CGamesPlay 8y agoThe motivation to prevent imaging is that an attacker can modify the device before it gets to the end user. With MDM, the IT department can audit all of the changes that have been applied post-Apple. And the IT department can use it to apply whatever changes they want to. So the gist of it is it’s “more secure than imaging”. My understanding is that the community hasn’t figured out how to do everything they need to with just MDM/DEP, so some imaging use cases still exist, and the community hasn’t figured out how to apply the MDM/DEP workflows to as many machines as quickly as the imaging workflow.
- antoncohen 8y agoIt sounds to me like imaging is the solution to attackers modifying systems during shipment. > Are you someone that needs to worry that a delivered device has been manipulated mid-shipment? > If you try placing a simple LaunchDaemon on a Secure Boot device’s System volume, it doesn’t stop it from booting in Full Security mode. That’s not one of the things in the signature manifest. With DEP/MDM the existing OS and files that were there doing shipment would still be there, DEP/MDM would just add additional things or change settings. With imaging you wipe out everything that was there during shipment and start fresh.
- CodeWriter23 8y ago> It sounds to me like imaging is the solution to attackers modifying systems during shipment. It’s not. They could hack the BIOS or the IME to establish a rootkit that is practically impossible to detect.
- josteink 8y agoMods: Title could be amended to mention that this is about imaging solutions for new Macs with Secure boot.
- lucb1e 8y agoAgree, but maybe the word provisioning is better. I initially interpreted the title as being about booting other OSes from Apple hardware, or perhaps a vuln in their secure boot firmware, but not about provisioning Apple hardware by booting from USB or something.
- brazzledazzle 8y agoThe security implications and what you do and don’t get out of it from a security perspective are discussed. Like you can drop a launchdaemon on it and that’s not evaluated as part of the system’s integrity. Only the boot process (for now).
- saagarjha 8y agoHow would you drop a Launch Daemon on the device if FileVault is enabled (as it is by default on all new Macs)?
- brazzledazzle 8y agoYou couldn’t disable it and reenable it?
- saagarjha 8y agoYou'd need the disk password to do that.
- brazzledazzle 8y agoI think there’s a misunderstanding here. He’s talking about modification of the Mac between Apple and the customer. I thought you were saying it’s pre-encrypted, my fault for misunderstanding.
- tpurves 8y agoAh. Does this explain why my IT department has frozen all new Mac distributions for the next 6 months because of the T2 chip?
- 21 8y agoIt's simple. When SecureBoot is done by Microsoft, it's a terrible thing that destroys all freedoms. All hardware with it should be boycotted. When it's done by Apple, it's a nice security feature, what's your problem?
- izacus 8y agoWhat you've never seen a hypocrite before? ;) Just look at amount of comments on Apple threads concerning their eager assistance to Chinese regime and amount of comments declaring Apple hardware as the second coming of the messiah in all other hardware threads.
- beagle3 8y agoCan you link to the instructions for disabling SecureBoot on microsoft ARM devices?
- deleted 8y ago[deleted]
- mjg59 8y agoFor laptop-style devices it's in the firmware configuration. For phones, well, can you link to the instructions for disabling it in iPhones? Microsoft's restrictions here are abhorrent, but they're also not outside the industry norms. The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
- beagle3 8y ago> For laptop-style devices it's in the firmware configuration. The discussion in https://news.ycombinator.com/item?id=15855195 https://news.ycombinator.com/item?id=15855195 indicates that, as of 7 months ago, this was not the case if those laptop-style ARM devices (the linked policy on microsoft's website is now 404). > The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing. It included Surface RT with keyboards, which were esentially laptop-style, at the point in time where Microsoft was still expecting other manufacturers to adopt RT (IIRC there were even a couple of samsung laptop models, quickly dropped).
- avhwl 8y agoCool write-up. This is one of the things that interested me about the new T2 computers; having a secure boot process that loads every link in the boot chain using cryptographic signatures verified by an onboard TPM engineered by some of the smartest people in hardware security. This isn't a move by Apple to lock users into their platform, they do that far more effectively through other means.
- saagarjha 8y agoIt really looks like a boot verification process to restrict which OSes can run on the device, à la iOS, which can only run what is current and signed by Apple.
- abalone 8y agoHas anyone heard any more details on how GreyKey bypasses secure boot on the iPhone? Do we know the T2 has fixed that flaw?
- saagarjha 8y agoLooks like Apple's implemented a significant part of the iOS boot chain security model here: I'm seeing AP Tickets, the Tatsu Signing Server (gs.apple.com), and personalization using ECIDs, all of which are part of the signing process for low-level boot on iOS. By the way, the iPhone Wiki has J137AP down as the iBridge processor, not the iMac Pro itself: https://www.theiphonewiki.com/wiki/J137AP https://www.theiphonewiki.com/wiki/J137AP