Copying login keychains between Macs fails on Secure Enclave Macs with Tahoe

Posted by zdw 2 days ago

Counter71Comment64OpenOriginal

Comments

Comment by shenenee 1 day ago

This is pretty much how it's suppose to work...

Comment by winstonwinston 1 day ago

Maybe but this is unexpected if you need to restore from a backup..

Comment by ryandrake 1 day ago

It's unexpected to anyone with intuition about how a computer traditionally is supposed to work. As a general principle, as a user, I expect a file on one computer to be usable on another computer. Or, at the very least, if I need to obtain some other thing from the original computer to "unlock" that file, I should be able to do it. The idea of a file that is only usable on a particular computer feels weird.

Comment by GeekyBear 1 day ago

> As a general principle, as a user, I expect a file on one computer to be usable on another computer.

As a general rule, I expect a file on an encrypted disk to be unreadable for anyone who lacks the encryption key(s).

> if I need to obtain some other thing from the original computer to "unlock" that file, I should be able to do it.

You can export your passwords to a plain text CSV from the original computer.

Comment by shaky-carrousel 1 day ago

As a general rule, I expect a file on an encrypted disk to be encrypted with a key derived from a password I provide.

Comment by wtallis 1 day ago

I think it's time to update your expectations. Hardware security modules have been around for quite a while. You shouldn't assume that your chosen password is the only input to the key derivation, or even that the raw key itself will always be obtainable.

Comment by shaky-carrousel 1 day ago

I never assumed that my chosen password was the only input to the key derivation. Just that my chosen password is at least one of the inputs to the key derivation. LUKS has been around for quite a while.

Comment by wtallis 1 day ago

You're asking for the encryption key to be derivable by an unrelated system that only has the encrypted file and your password.

Comment by kelnos 7 hours ago

Yes, in general that's how I expect (or at least want) things to work. And I'm a tech-savvy software developer.

Your average non-technical user will absolutely expect it to work this way, and if it doesn't, will be at best confused, and at worst incredibly angry that their photos are gone.

Comment by josephcsible 1 day ago

Yes, that's kind of what you need to be able to successfully back up and restore an encrypted file. Why are you making it sound like that's such a strange thing to want?

Comment by winstonwinston 21 hours ago

The sane way for encryption keys stored in hardware (secure enclave or tpm like) is to onboard user when the key is not derived from user password. Just like they do for FDE to export a recovery key and then you can adjust your expectations when you know (been told) whats going on.

Comment by shaky-carrousel 1 day ago

No, I'm asking for what LUKS has done for two decades. Keyslots are alternatives, not requirements, so a TPM slot and a passphrase slot coexist and either one alone unwraps the master key.

BitLocker does the same with key protectors. Even on a local account with no internet, there's always a 48-digit recovery password that opens the volume on a completely different machine.

Two of the three major platforms ship a portable passphrase path alongside the hardware one, so this being unavailable here is a product decision, not a law of key derivation.

Comment by frizlab 1 day ago

> You can export your passwords to a plain text CSV from the original computer.

Exporting a private key from a keychain is hard to automate (the password of the keychain is asked for all exports, and HAS to be typed manually IIRC).

Comment by ftchd 1 day ago

As a general rule, if I'm the user of both disks I expect to have the encryption key(s).

Comment by josephcsible 1 day ago

The right way to do that is FDE, where you can't even mount the filesystem to see the files without having the decryption key.

Comment by petronic 1 day ago

I've done Tahoe-to-Tahoe migration assistant moves between machines in recent months. No issues with login keychain migration.

Comment by winstonwinston 1 day ago

But that’s not backup restore? I’m thinking Time Machine restore on a new Mac when old one is no longer working. Or when the old one had to be wiped and restored.

Comment by lapcat 1 day ago

Migration Assistant uses the old Mac, which can unlock its login keychain and allow the keychain items to be copied.

Comment by pmontra 1 day ago

What if the old Mac is dead, stolen, lost? Those are the scenarios in which one recovers on a new machine from a backup.

Comment by lapcat 1 day ago

Then you're in trouble.

Comment by awakeasleep 1 day ago

What information from your login keychain do you expect to need on your new computer?

There's not really a plausible answer to that question, because the login keychain data is almost entirely specific to that host.

To iron-man your argument: Apps that store account credentials to third party services will need to be signed in again.

If you were using http basic auth for a website and saving that, then it was probably in there.

Private keys and certificates you manually imported, or that were created by an application for your host. This is the closest to a plausible answer, imo.

Comment by kelnos 7 hours ago

> What information from your login keychain do you expect to need on your new computer?

Pretty much everything?

Comment by Angostura 1 day ago

Migration assistant can also use a TM backup, I’m pretty sure

Comment by wl 1 day ago

It's also unexpected when you send your laptop in for a screen replacement, the tech does an unnecessary logic board swap while he's at it, and your local keychain doesn't work anymore. And then Apple Support will say, hey, we told you you needed to backup your data! Which you did, but that's not the issue.

Use iCloud Keychain or don't use Keychain at all.

Comment by adastra22 16 hours ago

I've learned to not trust Apple support on anything. My daughter's Watch screen cracked and we sent it in for a replacement. To setup the replacement though, they requried that she unpair then repair the watch then-and-there. They said she wouldn't lose any data, that it just disconnected it from the phone.

Nope, unpairing is a complete reset apparently. And Apple Support was apparently not trained to know that not everything syncs in the backup. She lost all her voice memos, which she uses for class notes, and probably other app data as well.

Comment by frizlab 1 day ago

Or create a separate keychain db and use that. The encryption is only done for the login keychain.

Comment by __MatrixMan__ 1 day ago

Don't backup keys, rotate them.

Comment by gavinsyancey 1 day ago

I can't rotate my keys if I lose access to accounts because my computer died and my backup is useless.

Comment by __MatrixMan__ 1 day ago

Yeah, that's why secure enclaves embedded in complex devices are a bad idea.

Hardware keys are the way:

- Less likely to fail in the first place

- Cheap enough to have several of so you can use one to log in and manage the others in the event of loss

- Easy to move between devices

- Less likely to use the auth handshake as a side channel for things you didn't consent to

Comment by pmontra 1 day ago

Can you clone or sync hardware keys? Maybe they don't fail as much as computers do but they can be lost or stolen like the keys that we use to open (dumb) doors.

My non hardware key is a keypass file that I update only on my laptop and I sync to my other devices. I have plenty of backups. It does also the TOTP required to login into some customers servers.

Comment by mingus88 22 hours ago

I have a few yubikeys and it’s a manual process to sync a new key last time I tried

I keep all my TOTP keys on an encrypted usb drive in a safe. When I lose a key, I manually add all the TOTP accounts onto the new key from my safe

Passkeys are a different story. Every account I need to make sure I have multiple yubikeys registered. When I lose one, I get in via a second key and then add the replacement one.

It’s a pain but it’s a model that makes sense to me. Lose the key? Time to reach for my backup key.

Comment by __MatrixMan__ 18 hours ago

Yeah it feels pretty dumb to have to register all of my keys with each service, but as far as I can tell it's the least dumb thing.

Comment by Retr0id 1 day ago

I'm more interested by the fact that it apparently didn't work this way before Tahoe.

Comment by pram 1 day ago

IIRC there are options for exportable and un-exportable private keys when you make one in the secure enclave. Going to guess Tahoe made them un-exportable by default.

Comment by kureikain 1 day ago

There is no way to export data out of secure enclave. You cannot write arbitrary data to secure enclave, as well as read it out.

What happen though is the ability to encrypt the data with secure enclave, store it on our own. When migrating, we decrypt with secure enclave, get back original data and re-encryp on the new device.

Comment by what 1 day ago

As far as I know, you have never been able to import or export keys from the Secure Enclave. It’s more likely that previously keys were stored in the keychain and now they are generated in the SE by default.

Comment by pram 1 day ago

Yes you can make private keys that are encrypted by the secure enclave, rather than stored inside it. The "sc_auth" tool on macos has a "ssh-exportable" variant

Comment by 1 day ago

Comment by lapcat 1 day ago

> This is pretty much how it's suppose to work...

No, it's not, and that's not how it ever worked in macOS 26.3 and earlier.

This change was introduced in 26.4 for some reason.

Comment by 1 day ago

Comment by xmddmx 1 day ago

Disturbing if true, as it suggests my "everything" backups aren't really full backups at all.

I wonder, if you have enabled iCloud keychain, does that provide another way to get your passwords back?

Suppose my MacBook is stolen, but I still have my iPhone. Could I use the passwords app on the iPhone to retrieve my passwords. Would that include all of them or only a subset?

Comment by ValentineC 1 day ago

> Disturbing if true, as it suggests my "everything" backups aren't really full backups at all.

Randomly, Chromium-based browser profiles can't perfectly copy across macOS machines either, because of some HMAC hashing that happens to extensions.

Comment by orbital-decay 1 day ago

You don't have any backups at all if you never tried restoring and testing them

Comment by nvme0n1p1 1 day ago

I tested restoring my restic backups to the same PC and it worked. If I was forced to use a mac and Apple's password manager, I'd probably do the same test, conclude it worked, and then later lose all my data. If you care about keeping your data, there's no substitute for understand how things work.

Comment by monster_truck 1 day ago

This is so critical. Not just verifying the hashes, not just restoring, but actually booting into it and opening the top 5-10 things you're going to care about.

If it's your personal stuff, skip it at your own peril. If it's a paid responsibility, that's what hourly billing is for (this incentive was much stronger when I learned netadmin, back before nvmes)

Comment by josephcsible 1 day ago

It's unreasonable to ask everyone to own a second computer just to test restoring backups on, and it sounds like doing the test on the same computer wouldn't have caught this problem.

Comment by lapcat 1 day ago

> doing the test on the same computer wouldn't have caught this problem.

Doing it on a second computer wouldn't have caught this problem either with macOS 26.3 and earlier, because it was introduced in 26.4.

Comment by lapcat 1 day ago

The iCloud keychain is separate from the login keychain. The Passwords app doesn't use the login keychain.

Comment by amluto 1 day ago

I have no idea which keychain is in which, but the last time I migrated from one Apple laptop to another, I couldn't get the automated tool to work at all, so I restored a physical backup, went through the sign-in process, and passwords and passkeys migrated correctly.

Comment by frizlab 1 day ago

Passwords and passkeys are in the iCloud keychain. You can technically save passwords in the login keychain (not sure about passkeys), but if you’re using the Passwords app it will be in the iCloud one.

Comment by xmddmx 1 day ago

Even more confusing. Do we know which data is in which keychain?

Comment by lapcat 1 day ago

Look in the Keychain Access app.

Comment by lubitelpospat 22 hours ago

Recently tried to initialize one Mac from another - kids, never ever attempt that! Microsoft stuff doesn't get copied over properly, and refuses to behave even if you delete an account and create a new one - the only solution is re-installing the OS from scratch. And if you want to do so, and you erase the disk - surprise surprise, in recovery mode macOS doesn't work with the WPA2/WPA3 Enterprise network; you need to go and find a WPA2 network somewhere to re-install the OS. Does the recovery menu explain that somewhere? Hell no. Damn, installing a linux distro from a usb stick is a better experience than re-installing macOS these days!

Comment by dfabulich 1 day ago

Does the macoOS login keychain get backed up by Time Machine backups in a way that could restore the keychain if the original machine's Secure Enclave is lost or destroyed?

Comment by 1 day ago

Comment by lapcat 1 day ago

Does the macoOS login keychain get backed up by Time Machine backups

Yes

> in a way that could restore the keychain if the original machine's Secure Enclave is lost or destroyed?

Apparently not

Comment by dfabulich 1 day ago

"Apparently"? Is this something that can be tested with VMs?

Comment by lapcat 1 day ago

I've tested with VMs. However, I'm unclear about the relationship if any between VMs and the secure enclave.

Comment by Jhsto 1 day ago

Switching from macOS to Linux was quite painful because the security was so seamless on Mac. But I also realized I had no idea how my passwords are stored and under what guarantees. Learning and getting the hardware tokens to do it properly on Linux was a PITA. But reading this post made me feel a pinch better.

Comment by neilalexander 1 day ago

Documentation explaining the Keychain security model: https://support.apple.com/en-gb/guide/security/secb0694df1a/...

Comment by ok_dad 1 day ago

It sounds like they are using envelope encryption and using the Secure Enclave to derive the row keys each time. Not really any easy way around that except they should provide a tool to export it, TBH. I am guessing they weren’t using envelope encryption before or they were deriving the row keys from the password. This is a secure design but more security usually means less usability these days.

Comment by tencentshill 1 day ago

It's always a good idea to plan to hang on to your old machine for a few weeks to ensure everything works properly on the new one. Apple makes that much easier to forget.

Comment by lapcat 1 day ago

This was introduced, unannounced, in macOS 26.4! See my blog post for more information: https://lapcatsoftware.com/articles/2026/9/4.html

Comment by 1 day ago

Comment by flyingshelf 1 day ago

And yet if you click export it will gladly print out a plaintext csv with your whole life in passwords. Doesn't even attempt to zip it with password or something.

Comment by ImPostingOnHN 1 day ago

that seems reasonable, as it is the lowest common denominator for interoperability

what would be unfortunate is if it was in some format that couldn't be used by most other systems without extra work, and if the user wasn't able to use their own property to export their own passwords in a different format.

Comment by eviks 20 hours ago

It's not reasonable to settle on the lowest common denominator as the only denominator

Comment by cute_boi 1 day ago

This is good.