Hacker News new | comments | ask | show | jobs | submit login
Apple T2 Security Chip: Security Overview [pdf] (apple.com)
362 points by chillaxtian 78 days ago | hide | past | web | favorite | 95 comments



One interesting point in the discussion of UEFI secure boot: it appears there is no way to boot OSes other than Mac OS and Windows without disabling secure boot entirely.

> 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.


> 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).


Last time this came around I believe it was shown that the process was similar to the one used in iOS.


With the very important difference that on the Mac, it can actually be turned off.


For now.


"it appears there is no way to boot OSes other than Mac OS and Windows without disabling secure boot entirely."

I am personally okay with that, so long as it can be turned off.


Can confirm that the T2 MPB on my desk right now can't see a clonezilla USB stick (booting with option key) even with "No Security" and "Allow booting from external media" checked

The stick boots fine on a non-T2 Mac Mini


Is it UEFI bootable? I believe thats a requirement with newer Macs.


Aha - it wanted GPT and also the 64 bit version.

Thanks for the pointer.


Well the good news is that changing the startup security preference for T2-featured Macs is straight forward and easily user accessible. Via Recovery partition, it has replaced the standalone Firmware Password Utility located in the Utilities folder and is referred to as Startup Security Utility.

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


>One interesting point in the discussion of UEFI secure boot: it appears there is no way to boot OSes other than Mac OS and Windows without disabling secure boot entirely.

Aren't there various linux bootloader shims signed by the MS key to workaround exactly this sort of regressive thinking ?


> 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.


Thank god - you wouldn't want that enabled by default.

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.


"All Mac portables with the Apple T2 Security Chip feature a hardware disconnect that ensures that the microphone is disabled whenever the lid is closed." It's interesting, I don't know if other brands do that?


I wish we had a physical switch that cut power to the camera and mic...

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.


The description makes it sound like Apple is using a hardware interlock that I'd assume cuts power to the microphone via a MOSFET when the lid is closed. That's pretty much the same thing, just with a solid state switch instead of a mechanical contact.


That's pretty cool.


It is pretty cool indeed, however keep in mind that's just standard component in circuits to turn signals on and off. It is just a PNP or NPN transistor. Everyone makes use of it.


To be clear too, I'm just speculating about that part. The only thing this document says is that "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." That implies to me that they are using some form of physical interlock (probably a magnet and Hall-effect sensor), and that they use this to completely disable the microphone. The most obvious way to me to do that in this case would be to cut the power with a transistor, but in principle there are a number of other ways it could be achieved.


I think it makes sense to assume they have a hall-effect sensor and a MOSFET but of course maybe they combined both in a single package.

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.


Purism laptops have hardware kill switches for camera/mic and wifi/bluetooth.

https://puri.sm/products/librem-13/


Unfortunately it has much weaker specs. No thunderbolt, only dual core CPU, slow Wi-Fi. They didn't even care enough to tell us the screen resolution, which is at least to me an important thing to know before buying.


Newer Thinkpads have a shutter to cover the camera, but mic still works when covered.

https://www.businessinsider.com/lenovo-thinkshutter-laptops-...


Yeah I got some handy shutters from some conferences, not a bad solution.


They say that "The camera is not disconnected in hardware because its field of view is completely obstructed with the lid closed."


And since the webcam in Macs electrically can't get power without also powering the green notification LED, it's impossible for malicious actors to activate the webcam silently while the lid is open.


Is that still true?

I read some time ago that the LED used to be hardware controlled, but switched to being software controlled at some point.


I wonder how long it will be until someone manages to figure out how to use image processing to read the noise seen by the camera sensor while the lid is closed and turn it into audio.

Kind of like this: http://news.mit.edu/2014/algorithm-recovers-speech-from-vibr...


That's certainly an interesting thought, but do note (from the linked article):

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?


From the next paragraph:

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.


Does this mean you can't use it in a configuration with say one laptop, two external monitors, and lid closed... and still use the mic?

I don't have a Mac so maybe that isn't a valid use anyway, but I do that with PCs all the time.


I don’t think the audio quality of the mic on a closed laptop is going to be something you’d actually want. Plus it likely only applies when the machine is entering sleep?


Older MacBook Pros had their microphones on the exterior of the laptop, on the left side, so I'd imagine the sound from that would be pretty decent. Newer Macs put it inside the speaker grill, I think, so this wouldn't really work.


Nope, since the first MacBook Pro the dual-microphones have been placed in the grill, with the PowerBooks and iBooks the single microphone was placed in the left side of the display panel in a small hole.

The white/black MacBooks, I believe, placed it near the iSight camera.


The MacBook Pro I'm trying this on, a MacBook Pro (Retina, 13-inch, Early 2015), has the microphones on the left side next to the microphone jack.


The mics are on the left hand side on that model.

https://www.ifixit.com/Guide/MacBook+Pro+13-Inch+Retina+Disp...


…that's what I said?


Has this place become such a cesspit that you can't countenance the possibility I'm simply supporting your position and backing it up with evidence? Perhaps I should have added the word 'yes' as the first word.

And someone felt the need to down vote a reply simply containing evidence that proves a commenter correct? I despair sometimes.


Never knew that countenance could be used like that. TIL


It is a valid use case, and no it seems like it won't work.


TY, interesting.

Granted, I get that for security ... can't be bending the rules or it would just be the method use to circumvent it.


Also, since the mic would be covered by the lid, you probably wouldn't want to use it anyway under this scenario.


>seems like it won't work

Are you speculating here or do you have some kind of insight?


I have a T2-equipped MacBook Pro and when in clamshell mode the input monitor for the mic is dead.

Cracking it open makes it spring back to life.

So yes, the microphone is disabled in clamshell mode if connected to displays.


It is for security reasons, disconnected by hardware when the lid is closed so that not even the T2 has access to it(or any hacker trying to listen in on you). Facetime camera works however, as closed lid essentially prevents it from seeing anything anyways.


I think he is speculating, but any work around to bypass the rules related to the security chip would seem unlikely.


Or maybe we're just reading it too literally and the document actually means "when the computer is asleep" but they said "when the lid is closed", thus creating the confusion? But I guess if it's about "sleep" mode, that's too easy to bypass in software without even attacking T2...


The wording in the document is pretty strong, though. I'd speculate the same.


I wonder what determines whether or not the lid is closed.


Why you need security chip to ensure that?


So no malware can be installed to override a software based interlock. No malware can alter the contents of the T2 chip so code there cannot be changed, altered or mitigated.


The T2 chip is just an ARM CPU running a customized version of watchOS. So in theory malware could take over control of the T2 chip.

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.


To prevent nefarious software from listening in unknown to you.


Why it needs to go trough security chip?

Laptop closed -> microphone cut off does not need complex logic. It's just simple switch.


Hardware switches are more expensive and less durable.


the NSA/CIA/3LA can't backdoor a physical switch


Why not?

Do you have schematics of your laptop?


I don't think you do, it's just an additional security feature that they put in the T2 PDF for some reason.


If the trigger is mechanical it's ok, but if the trigger is electrical (and handled by some hardware) then the chip is useful.


So Bloomberg has something for a slow news day.


:) !


Because if you don't mention that you've got a hardware switch covering the mic someone will ask you why your security chip has this glaringly obvious hole in it.


I wonder how that works for the Mac Mini. I'm honestly not sure if it even has a microphone built in or not.


The Mac Mini isn't a portable, so not at all?


AFAIK it doesn't. You need to provide your own microphone.


Previous gen didn't, so I doubt the new gen does.


Very interesting indeed.


What happens if the T2 Chip fails? Is it possible to recover data on the disk? Or do we have to recover data from the last backup?


It's probably impossible if the T2 itself fails; I imagine the encryption keys are in there. Data recovery is possible if the T2 is working: https://9to5mac.com/2018/09/20/apple-t2-data-recovery-transf...


With multiple points of failure, backups become so much more important.


As an example, the current gen Macbook Pro has an SSD that is soldered to the motherboard (so you obviously can't remove it and cable it up to USB via an adapter to extract data).

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.


The current generation of MacBook Pro doesn't have such a recovery port for the SSD anymore. The MacBook Pro 2016 and MacBook Pro 2017 had such a port, but the MacBook Pro 2018, which features the T2 chip, doesn't. As the encryption keys are located inside the T2 chip, if that chips breaks, all data on the SSD is lost.


>As the encryption keys are located inside the T2 chip, if that chips breaks, all data on the SSD is lost.

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.


I had been using iCloud for backup up until a DJ gig where I came to realize that upon enabling iCloud it had automatically moved all my AIFF music files to the cloud, leaving only a symlink behind. So that gig was a failure and pretty unprofessional. I disabled iCloud and a few days later kaboom, the Macbook died! I lost everything. My mistake for assuming the SSD could be removed and plugged in via an USB caddy.

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.


I'm just waiting for the Rossmann video when someone manages to spill some Coke on their T2 chip...

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.


And the same goes for whoever steals/subpoenas your machine.

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.


> And the same goes for whoever steals/subpoenas your machine.

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...


Then they are not encrypted.


Encrypted using passwords = not encrypted. Yeah, okay, tell that to the FBI who couldn't break TrueCrypt only a few years ago.


Unless they let you export the keys, difficult conversation time.

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...


You can store recovery keys externally if that is consistent with your threat model.


Is there anything different in the T2 chip introduced today in MacBook Air and the one in the MacBook Pro released earlier this year?


Doesn't appear to be. Apple lists the MBP and iMac chips as one and the same - assume that the MBA would be added to this list. https://support.apple.com/en-us/HT208862


> line-speed encrypted storage

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?


It means that it can encrypt and decrypt data at the same speed as the interface/underlying storage. Encrypted storage doesn't slow down storage versus unencrypted usage.


More information on the GID/UID can be found in the iOS Security Guide:

> 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....


[deleted]


The T2 is utilizing a physically unclonable function (PUF) and TRNG to create a public/private device key pair on die. At manufacturing, the T2 exposes the device public key to Apple, Apple signs with a group key posted to their CA. This is why they say they can revoke privileges via the CA. It's unclear to me whether the T2 regenerates this key pair each time it is requested, or whether it is encrypted and stored in memory. In the event the latter is the case, the encryption is being performed inside the secure enclave. "Secure enclave" used here is almost certainly distinct from Intel SGX, ARM TrustZone and the like. The page tables are protected. Row Hammer, Spectre, Meltdown and Foreshadow do not apply to something like T2, as the OS is considered trusted. The fundamental challenge that e.g. Intel's SGX has over this type of architecture is that a dedicated security co-processor doesn't need to maintain speculative execution behaviors necessitated by performance requirements, which expose numerous sidechannel attacks, and likely has minimal need to assume untrusted code operating in the T2 OS.


"line speed encrypted" ~= "encryption that goes as fast as the device would if not encrypting"


I don't have any insight into the details, but I'd guess that under the hood (and not-so-under the hood) it looks and behaves a lot like a TPM


Indeed. Since Apple controls the full hardware and software stack, it's not surprising that they are making their own security chip without any of the ugly downsides of TPM (TPM has more complex interfaces and logic that try to cover a broader set of use cases than what Apple support). As another upside, they are also not reliant on any supplier code for the chip.


anyone who uses eGPUs (w/ Nvidia): whenever I setup my MBP shortly after buying (middle of this year), one of the steps required disabling Secure Boot and another security item via terminal. Is that still the case? Pretty sure my T2 chip is disabled due to this. Not a major loss if it must remain that way, but wasn't sure if it was just mitigating something that is no longer an issue.


> one of the steps required disabling Secure Boot and another security item via terminal

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.


It’s no longer required; High Sierra and Mojave both officially support eGPUs.


I'm of two minds about how the T2 safeguards access to storage. On the one hand, safeguards like these are a great step forward for endpoint security to guard against device theft. On the other hand, if you break your machine in some way that your storage is still intact - too bad, you're locked out.

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.


upvoting because I want people who know more than me about security to see and comment. :)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: