Apple T2 Security Chip: Security Overview [pdf]
apple.com
apple.com
> By default, Mac computers supporting secure boot only trust content signed by Apple. However, in order to improve the security of Boot Camp installations, support for secure booting Windows is also provided. The UEFI firmware includes a copy of the Microsoft Windows Production CA 2011 certificate used to authenticate Microsoft bootloaders.
> NOTE: There is currently no trust provided for the the Microsoft Corporation UEFI CA 2011, which would allow verification of code signed by Microsoft partners. This UEFI CA is commonly used to verify the authenticity of bootloaders for other operating systems such as Linux variants.
It isn't clear whether new root CAs can be added or if there is a customer-accessible setup mode for secure boot at all.
Another part of the discussion is about the various levels of secure boot enforcement. In the default "Full Security" mode, the Mac OS setup (or Boot Camp assistant for Windows boot) requests that Apple sign the OS boot loader with a signature derived from the T2 chip's unique ID, and then the boot firmware on the T2 checks for this machine-specific signature on boot. As I understand it, Apple claims that by simply changing its online service to deny signing certain boot loaders, it can prevent many OS downgrades to versions with known vulnerabilities.
That seems like a very reasonable ability considering that "Full Security" mode says, "This mode requires a network connection at software installation time."
I'd guess it's a challenge/response deal with the T2 in your Mac issuing a challenge to Apple. The response could be as simple as Apple signing the signature of its software with the challenge, i.e. response = sign(challenge + sign(MacOS))
Presumably it's whatever Apple currently does for iOS, as my understanding is that it has the same downgrade protection feature and that is part of what makes jailbreaking so precious, you need to be on the vulnerable version of iOS in the relatively short window it's still being served by Apple (aka before Apple patches some or all of your exploit chain).
Aren't there various linux bootloader shims signed by the MS key to workaround exactly this sort of regressive thinking ?
Some people might want secure boot with their own certs to work with Linux, but I don't see the gain in security if you are using a generic boot loader.
I am personally okay with that, so long as it can be turned off.
The stick boots fine on a non-T2 Mac Mini
Thanks for the pointer.
Default installations of MacOS do enable both the Secure Boot option "Full Security" and disable the Mac's ability to startup from external media however via this utility you can change that preference to "allow booting" for the latter and an option called "Medium Security" for the former. Medium Security would allow the Mac to startup from any previously trusted & signed OS, thus allowing the user the ability to downgrade (& without an internet connection) if needed. I can personally attest that if these T2 Macs were ever eligible for a build of MacOS, they can downgrade to it.
The real question is which users or administrators are majorly impacted by the T2 Mac's inability to boot into a network volume. From what I've heard, this is a T2 restriction that cannot be bypassed. This will fundamentally change the way ACMTs can service Macs going forward.
-About Startup Security - Apple Support: https://support.apple.com/en-us/HT208198
Off the top of my head, Macs with T2: 2017 iMac Pro/ 2018 13" MBP/ 2018 15" MBP/ Late 2018 MacBook Air/ Late 2018 Mac Mini
I worked on some old networking equipment a while back that had a physical fail over switch. If you opened the cover you could watch the connection switch, fun stuff. Also very effective.
Thinking how a hall-effect sensor works, perhaps it would be possible to embed it in a wafer with some gates and you're done.
https://www.businessinsider.com/lenovo-thinkshutter-laptops-...
I read some time ago that the LED used to be hardware controlled, but switched to being software controlled at some point.
Kind of like this: http://news.mit.edu/2014/algorithm-recovers-speech-from-vibr...
In some of their experiments, the researchers used a high-speed camera that captured 2,000 to 6,000 frames per second..
I haven't checked, but I would be surprised if Apple uses cameras that are capable of that as normal user-facing webcams in their laptops ...
Recovering meaningful audio signal (which usually has lots of data above 1 kHz) from the <100 Hz sampling done by a camera seems difficult, Nyquist and all, right?
In other experiments, however, they used an ordinary digital camera. Because of a quirk in the design of most cameras’ sensors, the researchers were able to infer information about high-frequency vibrations even from video recorded at a standard 60 frames per second.
I don't have a Mac so maybe that isn't a valid use anyway, but I do that with PCs all the time.
Granted, I get that for security ... can't be bending the rules or it would just be the method use to circumvent it.
Are you speculating here or do you have some kind of insight?
Cracking it open makes it spring back to life.
So yes, the microphone is disabled in clamshell mode if connected to displays.
The white/black MacBooks, I believe, placed it near the iSight camera.
https://www.ifixit.com/Guide/MacBook+Pro+13-Inch+Retina+Disp...
And someone felt the need to down vote a reply simply containing evidence that proves a commenter correct? I despair sometimes.
Laptop closed -> microphone cut off does not need complex logic. It's just simple switch.
Do you have schematics of your laptop?
I also wonder what implications on features like the mentioned microphone disconnect that'd have. My guess is that the T2 chip which also acts as audio controller, simply doesn't forward audio signals received from the microphone to macOS if the lid is closed.
Edit: Never mind. After reading further it becomes clear that it's really disconnected in hardware:
> This disconnect is implemented in hardware alone, and therefore > prevents any software, even with root or kernel privileges in macOS, and even > the software on the T2 chip, from engaging the microphone when the lid is > closed.
Apple installed a port on the motherboard that their techs can use to recover data if the motherboard fails. But sure enough it didn't work with my 11 month old Macbook Pro.
Moral of the story... even if Apple has a mechanism for hardware failures, there's a chance it won't work.
All my "valuable" stuff is on github, or google drive, or icloud photos or something-or-other. My local drive is really just a local "cache" for speed purposes.
I don't see how else you're expected to not lose sleep at night anymore.
Apple replaced everything except the bottom case. I picked up the laptop with 100% charge, tested it was working. I jumped on a flight home (no apple store in my country) and that night kaboom, Macbook died again! What are the odds? I hadn't plugged it in to anything. The eventually agreed to give me a brand new one.
The positive side of this experience was forcing me to use an iMac and only work from home office during specific hourse and to not be attached at the hip to my laptop. Net positive for my wife and I.
Shit like this is why I will never buy another Apple product. With my encrypted drives I can pull them out, put them in another machine and decrypt them no issues.
Shit like this is why I only buy Apple products.
The data I care about I have (encrypted) backups of. Not having backups and hoping that a specific hardware failure will not affect my ability to restore is equivalent to, well, just not having backups to begin with.
Yes, because clearly all other encryption technologies are so vulnerable to theives and cops. There's only a pile of evidence of TrueCrypt and Bitlocker being quite effective in the field against both criminals and law enforcement agents.
And that's not to mention SSD-based technologies which still allow for portability while mitigating some of the more theoretical attacks.
> The data I care about I have (encrypted) backups of. Not having backups and hoping that a specific hardware failure will not affect my ability to restore is equivalent to, well, just not having backups to begin with.
This is a good strategy, I too employ it with the majority of my important data, but it's just not realistic for normal people. And I'm sure I'm forgetting some scratch note or IDA database file that I'd be missing if I lost my desktop drive today...
I did some support for some encryption devices a long time ago.
If someone was having that difficult conversation (you could just tell it was about to happen) we would all silently gather around to hear how it went...
What does this mean?
> The Mac unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the Secure Enclave during manufacturing. No software or firmware can read the keys directly
Does anyone know the details underlying this?
> With the exception of the Apple A8 and earlier SoCs, each Secure Enclave generates its own UID (Unique ID) during the manufacturing process. Because the UID is unique to each device and because it’s generated wholly within the Secure Enclave instead of in a manufacturing system outside of the device, the UID isn’t available for access or storage by Apple or any of its suppliers.
> Software running on the Secure Enclave takes advantage of the UID to protect device-specific secrets. The UID allows data to be cryptographically tied to a particular device. For example, the key hierarchy protecting the file system includes the UID, so if the memory chips are physically moved from one device to another, the files are inaccessible. The UID isn’t related to any other identifier on the device. The GID is common to all processors in a class of devices (for example, all devices using the Apple A8 processor).
https://www.apple.com/business/site/docs/iOS_Security_Guide....
Probably SIP from Recovery Mode. This doesn't disable your T2 chip completely, since it's still necessary do things like control your camera and microphone or read from your SSD, but it disables certain protections.
What Apple is really saying with this kind of design is that you need to treat your machine as if it were disposable. You won't worry about losing your data if your laptop only has a cached copy. If your machine breaks, ditch it, get another one, redownload your data from the cloud.
But most customers don't actually use their Macs this way. They don't see their highly-priced luxury machines as disposable. They don't pay for cloud storage; if they do, then they don't keep all their data backed up to their cloud storage accounts, and they expect that their original data will still be available. They don't have 3-2-1 backup strategies and they don't plan for being locked out of their cloud backups.
So this doesn't feel to me like Apple focusing on security. It feels like the security-focused extension of Apple's general strategy: rising prices and declining repairability as the basic formula for strategic revenue growth from their Western upper-class customer base. And that's something to be resisted.