"Enter your passcode to trust this computer and start a backup." Every time iPhone is on charge.

The real reason is so a hacker cannot force a download of your iPhone without your knowledge and steal all of your personal data from the downloaded backup. But your conspiracy theory is so much more fun.

Here’s the explanation from a disinterested 3rd party→iOS Backup Passcode Prompt-iMazing

And here’s the explanation from the discoverer of this vulnerability→https://theevilbit.github.io/posts/cve-2022-32929/

I dunno...seems that everyone has missed the most critical part. You're assuming that the mac it's being stored on has been successfully invaded. That means the bad guys ALREADY own all your data. It means that the person who owns that machine probably doesn't have a decent antivirus, because it's a known agent. And given the world we live in, you have to be pretty stupid not to have one.

But that aside, the solution is so obvious that Apple not having seen and corrected it is yet another demo that they've strayed pretty far from what they once were.

Since the data is only used on the phone, and is never accessed while being stored, be it a Mac or the cloud, you encode the phone data on-the-phone, so what's sent to either the cloud or the mac is unreadable at the storage end. That way, even if Apple's storage is hacked, the data is unusable.

Then how can the phone owner use the unreadable data? They can’t use it to restore a phone, because the key to unlock the backup was wiped when the phone was reset. And you can’t use the backup to set up a new phone for the same reason.

Known agent? You mean you have never heard of a zero day flaw? Antivirus, if you have it, and keep it updated, doesn’t know about new vulnerabilities for weeks after they have been discovered by hackers most of the time.

Did you actually read the links I posted? Do you realize that more iPhone users have Windows than have macs? Do you know more about data security than the researcher who discovered this vulnerability or Apple’s cybersecurity team?

Hello. Did you ever get this problem resolved with your phone? Mine started this last week and it's not connected to my computer nor is it connected to a charging device. My wifi and bluetooth are off it continues to do it. I've restarted my phone and my automatic updates are turned off. I do have ios 16.2. Any suggestions?

• Then how can the phone owner use the unreadable data? They can’t use it

to restore a phone, because the key to unlock the backup was wiped when

the phone was reset. And you can’t use the backup to set up a new phone

for the same reason.

Seriously? If the data is encrypted by-the-phone, and done AS it's sent to backup, there's no need to do anything but store it—be that on a local computer or any kind of cloud server. And of course, the phone can upload and use the data, because it, and it alone, has the encryption key. Sending unencrypted data that can be intercepted on the way to storage, and THEN encrypting it, is dumb.

The number of screw-ups on the part of Apple—screw ups that their quality control testing should have caught, keeps growing.

If we stop doing the thing that Apple screwed up it won't happen? Sure, but that's a workaround, not a solution. And for some, it means running an extension cord, so they can use the phone while it charges.

JayGreenstein wrote:

• Then how can the phone owner use the unreadable data? They can’t use it

to restore a phone, because the key to unlock the backup was wiped when

the phone was reset. And you can’t use the backup to set up a new phone

for the same reason.

Seriously? If the data is encrypted by-the-phone, and done AS it's sent to backup, there's no need to do anything but store it—be that on a local computer or any kind of cloud server. And of course, the phone can upload and use the data, because it, and it alone, has the encryption key. Sending unencrypted data that can be intercepted on the way to storage, and THEN encrypting it, is dumb.

But when you restore an iPhone from a backup the first step erases the phone, so it no longer has the encryption key. And what about the other, more common, use of backups? Moving the contents of a backup to a new phone, which certainly doesn’t have the encryption key.

he number of screw-ups on the part of Apple—screw ups that their quality control testing should have caught, keeps growing.

• But when you restore an iPhone from a backup the first step erases the phone, so it no longer has the encryption key.

Hmm... so you figure that if the Apple people changed the system so that it was encrypted at that end they wouldn't be smart enough to retain the decryption key as part of the restore operation?

Normally, I'd laugh at you not seeing that, but given the total number of screwups by them lately...

• Moving the contents of a backup to a new phone, which certainly doesn’t have the encryption key.

That's easy. Lots of ways around that. For example: When the phone is told to encrypt data being backed up by the user, at the next backup initialization, and at the phone's initialization, the key is sent to the computer, or iCloud for permanent backup storage. Thereafter, until the phone user changes it, it's never used again. And because it's encrypted by the computer, it's all safe. There are other ways, but that's the easiest.

I'm surprised you didn't see that.

JayGreenstein wrote:

• But when you restore an iPhone from a backup the first step erases the phone, so it no longer has the encryption key.

Hmm... so you figure that if the Apple people changed the system so that it was encrypted at that end they wouldn't be smart enough to retain the decryption key as part of the restore operation?

Smart enough? They would be smart enough NOT to save the encryption key. Where are they going to save it? All storage on an iPhone is encrypted. When you reset the phone the storage encryption key is erased to clear storage. Are you suggesting that somehow some storage NOT be encrypted just to save this key? That’s a back door.

ormally, I'd laugh at you not seeing that, but given the total number of screwups by them lately...

• Moving the contents of a backup to a new phone, which certainly doesn’t have the encryption key.

That's easy. Lots of ways around that. For example: When the phone is told to encrypt data being backed up by the user, at the next backup initialization, and at the phone's initialization, the key is sent to the computer, or iCloud for permanent backup storage. Thereafter, until the phone user changes it, it's never used again. And because it's encrypted by the computer, it's all safe. There are other ways, but that's the easiest.

I'm surprised you didn't see that.

I did see it, and rejected it as a major security vulnerability if the key is on the computer, it is a back door. I’m surprised you don’t realize that.

• Smart enough? They would be smart enough NOT to save the encryption key. Where are they going to save it?

Oh I don't know. Perhaps where they save it now for doing the encryption on the computer or cloud?

• All storage on an iPhone is encrypted.

THINK! Were that true, there would be no need to encrypt the data before storing it on the computer, and no need for a password before backup. The supposed bad operator that you claim is stealing data would get only encrypted data from the phone, so there would be no reason to care if a virus was calling for a backup, and therefore no reason to call for the user to type their password. So either Apple screwed up even worse than we thought or you're wrong about the phone encrypting the data.

And further, if there is no encryption on the phone, assume that the bad operator you postulate sent a request for backup, and the password request came up. If that happens, the vast majority of users would supply it. And once the bad guy has the data they wouldn't have reason to ask again, so the user would never know it happened.

That's why that constant password business was nonsense from the start.

Do you even think about what you say? Seems to me that instead of looking at the problem and seeking a solution, you're focused on finding fault with anyything that everyone else says.

• I did see it, and rejected it as a major security vulnerability if the key is on the computer, it is a back door.

Hmm... if an encryption key is sent to the computer only at the phone's direction—once—then encripted and stored, that's a backdoor? Seriously?

You have absolutely no understanding of how iPhones and backups work, yet you are proposing solutions that cannot possible work. Or perhaps you are just trolling.

JayGreenstein wrote:

• All storage on an iPhone is encrypted.

THINK! Were that true, there would be no need to encrypt the data before storing it on the computer, and no need for a password before backup. The supposed bad operator that you claim is stealing data would get only encrypted data from the phone, so there would be no reason to care if a virus was calling for a backup, and therefore no reason to call for the user to type their password. So either Apple screwed up even worse than we thought or you're wrong about the phone encrypting the data.

THINK! That IS true, however, what is NOT true that you seem to be assuming is that a backup is just a cloned image of what is on the phone. A backup is a collection of individual data items from each application database on the phone stored as a SQLite database, each in its own unencrypted file (unless the user choses to encrypt the backup, but most don’t). A single backup is thousands of individual files; one of my backups is over 60,000 individual files.

nd further, if there is no encryption on the phone, assume that the bad operator you postulate sent a request for backup, and the password request came up. If that happens, the vast majority of users would supply it. And once the bad guy has the data they wouldn't have reason to ask again, so the user would never know it happened.

That's why that constant password business was nonsense from the start.

Do you even think about what you say? Seems to me that instead of looking at the problem and seeking a solution, you're focused on finding fault with anyything that everyone else says.

• I did see it, and rejected it as a major security vulnerability if the key is on the computer, it is a back door.

Hmm... if an encryption key is sent to the computer only at the phone's direction—once—then encripted and stored, that's a backdoor? Seriously?

Yes, but I’ve concluded that you are simply trolling, so this is my last response to you.

• That IS true, however, what is NOT true that you seem to be assuming is that a backup is just a cloned image of what is on the phone.

No, that's your unproven assertion. I never said or implied that. I spoke of "the data" and never mentioned the internal workings or format of the phone. Did you actually read what I said? It seems not.

• A backup is a collection of individual data items from each application database on the phone stored as a SQLite database, each in its own unencrypted file

To quote you for the SECOND time: "All storage on an iPhone is encrypted."

So, if your "unencrypted" claim is valid, my suggestion that files sent to the computer be encrypted as they are sent, instead of after arrival, solves the problem. If your prior claim is valid, and it's already encrypted, there's no need to worry.

Either way, the answer is to do it in the phone. You really need to do a reasonability check on what you say. You're letting yourself view anything said in any forum that's not in total agreement with your views as a battle that must be won at all costs. That's always a mistake.

[Edited by Moderator]

Not sure what you have, but iTunes went out about 2 versions of IOS back, this is an issue, and the older IOS is remembered in your keychain choice when paired with your laptop or desktop whichever variety you use. It is purely on the backup portion of the service. Yes it is annoying, another Apple decision based on their security preferences and taking control away from users/customers.

You know it is a mistake when it forces you to type in passcode and not just use fingerprint, apple not making much sense.

[Edited by Moderator]