Mismatched Trust Store Version on iOS 16.5

If you are referring to this article where they are referring to iOS 16 and not iOS 16.5 --> List of available trusted root certificates in iOS 16, iPadOS 16, macOS 13, tvOS 16, and watchOS 9 - Apple Support (IN)

iOS 16, 16.3, and 16.5 have different Store Versions and Asset Versions. Please go through my entire post

This is the correct trust store version for iOS 16.5 - 2023032800. Please see the pic below on iOS 16.5 iPhone 12 Pro.

Learn about Available trusted root certificates for Apple operating systems - Apple Support

This is part of iOS updates which can be clearly seen below

All my devices, iPhone 8 (iOS 16.0), iPhone 12 Pro (iOS 16.1.1) & iPhone 13 Pro on iOS 16.1.1 also iPad Pro on iPadOS 16.1 are with Trust Store Version: 2022070700 and Trust Asset Version 18

iPhone SE (1st Gen) iOS 15.7 2022031500 and Trust Asset Version 18

Earlier, iPhone 8, SE (1st Gen), iPhone 12 Pro & iPhone 13 Pro on iOS 15.6.1 also iPad Pro on iPadOS 15.6.1 all are with Trust Store Version: 2022031500 and Trust Asset Version 17

iPhone 6 iOS 12.5.5 Trust Store Version 2018121000, Does not have Trust Asset Version

After updating my iPhone 6 to iOS 12.5.6 it still has Trust Store Version 2018121000, Does not have Trust Asset Version

There is an old discussion thread on Trust Asset Versions that may help you understand --> Trust asset version 11. - Apple Community

Please check the iOS versions on each device again

Learn about Available trusted root certificates for Apple operating systems - Apple Support

This is part of iOS updates which can be clearly seen below

iPhone 12 Pro iOS 16.3 Trust Store Version: 2022070700 and Trust Asset Version 20

iPhone 8 iOS 16.2 Trust Store Version: 2022070700 and Trust Asset Version 20

iPad Pro 9.7" iOS 16.2 Trust Store Version: 2022070700 and Trust Asset Version 20

iPhone 13 Pro iOS 16.2 Trust Store Version: 2022070700 and Trust Asset Version 20

I may have missed Asset Version 19

All my devices, iPhone 8 (iOS 16.0), iPhone 12 Pro (iOS 16.1.1) & iPhone 13 Pro on iOS 16.1.1 also iPad Pro on iPadOS 16.1 are with Trust Store Version: 2022070700 and Trust Asset Version 18

iPhone SE (1st Gen) iOS 15.7 2022031500 and Trust Asset Version 18

Earlier, iPhone 8, SE (1st Gen), iPhone 12 Pro & iPhone 13 Pro on iOS 15.6.1 also iPad Pro on iPadOS 15.6.1 all are with Trust Store Version: 2022031500 and Trust Asset Version 17

iPhone 6 iOS 12.5.5 Trust Store Version 2018121000, Does not have Trust Asset Version

After updated my iPhone 6 to iOS 12.5.6 it still has Trust Store Version 2018121000, Does not have Trust Asset Version

There is an old discussion thread on Trust Asset Versions that may help you understand --> Trust asset version 11. - Apple Community

Where did you see 2022070700? That is an almost year old version. The trust store version number is the date that the trust store was last updated, and for iOS 16.5 it is 2023032800.

In simple terms, The Trust Store contains the digital signatures of issuers of the SSL certificates that are used to encrypt access to websites and email servers. There are billions of SSL certificates in use around the world. They are issued by a relatively small number of agencies and companies (called Certificate Authorities, or CAs), who, as part of the process of issuing the certificate, verifies that the site is legitimate. When you visit a website the certificate from that site is sent to your browser. Your browser then verifies that the certificate was issued by one of the agencies whose signature is in the Trust Store. If the signature is not in the trust store you see a warning that the site may not be what it seems. The Trust Store is updated as part of an iOS update. It will change whenever the list of certificate authorities changes, which is very rare. The Trust Store version is actually the date and time the trust store contents were last updated. So, for example, version 2023032800 was last updated on March 28, 2023 at midnight.

The trust store version has absolutely nothing to do with security vulnerabilities. If you keep your Apple product updated to the latest version of MacOS or iOS it will be protected against all known vulnerabilities, despite whatever mis-information has been posted in the forum. 

https://discussions.apple.com/thread/253150767

Bite-1T wrote:

?? Me too. 2023032800

Trust asset version:20

The Trust Store is not related to carrier lock.

Trust Store 2023032800 is current.

Apple hasn’t updated their support article.

You can send Apple some feedback, or can contact Apple Support and confirm this.

MissFiddy333 wrote:

Do you know how to delete this root certificate and regain my normal trust asset version?

Delete the Comcast Xfinity app, and restart the iPhone.

That deletion should clear that, and should also prevent you from accessing the secure Comcast Xfinity Wi-Fi networks.

MissFiddy333 wrote:

I’m concerned my trust asset version is 1002. Apple only has up to 21 from research I have done. My mother’s phone on the same plan shows this …

https://discussions.apple.com/content/attachment/520eac73-d7c0-4ad1-bd05-962998037915

I'm concerned I have a root certificate and it’s forced.

It is associated with a carrier (ISP) app you have installed.

I cannot remove it.

Remove the Comcast Xfinity app.

Doesn’t that usually mean a iphone is jail broken?

No.

I’ve had iPhones since the 1st one came out. I’ve never seen a root certificate installed on my iPhone. My family has the same xfinity service on the same plan and none of their iPhones show this root certificate.

Do they have the same carrier apps installed, or a carrier-recommended profile installed?

https://forums.xfinity.com/conversations/xfinity-mobile/wifi-hotspot-security-profile-wont-update/61ac09ce50b737295336a27f

https://www.xfinity.com/support/articles/secure-vs-open-xfinity-wifi

https://www.xfinity.com/support/articles/download-xfinity-wifi-app-prioritize-home-network

T3ddy19 wrote:

I should mention, generally when you go to a secure site, like Amazon and it’s https, it will install a security cert for that site.

That is incorrect.

Visiting a website with a trusted certificate does not “install a security cert for that site”.

The Apple certificate trust store being discussed in this thread is what avoids that certificate download and that manually-trusted certificate.

Yes, it is possible to access a website that is configured with a self-signed or expired or untrusted certificate, and that access will show an untrusted certificate error. It will not automatically “install a security cert” for that website, however.

It is possible to manually load a trusted certificate to include trust for a particular website or service or organization, but that is not the common case, and that is not the default behavior.

But I don’t see a list stored anywhere?

Because there isn’t one. The trusted certificate store is a fundamental part of iOS, iPadOS, and macOS, built into the platform, and expressly protected against modifications by users or apps.

If you are interested in learning how public key encryption and certificates work in general terms, there are available resources. (Here is a Khan Academy intro.)

MissFiddy333 wrote:

I’m concerned my trust asset version is 1002. Apple only has up to 21 from research I have done.

According to the following thread, the Trust Store Version is a date, followed by a sequence number. So 2022070700 translates to (July 7, 2022; sequence number 00).

The Trust Asset Version "is an arbitrary internal version number" and the version numbering "does not necessarily follow a linear count."

Trust Asset Version - Apple Community

So what's the problem?

Hi, I bought this iPhone from Trust store version 2023032800 or Trust asset Version 20 and this is the 11 Pro Max iPhone. I did insert my previous phone number SIM card in it but I can’t cause it says CARRIER LOCK AND THIS DEVICE MIGHT BE RESTRICTED TO THE ORIGINAL CARRIER AND OR HAVE CERTAIN CAPABILITIES LIMITED. the previous carrier has to unlocked or confirm that’s all I’ve wanted please and thank you !

As someone with IT experience, you will want to collect configuration details and forensics details and engage someone that can provide assistance with what is a catastrophic exploitation of multiple devices and disparate operating systems. Again, as someone with IT experience, you will clearly recognize that assistance with the sheer scale of exploitation you are reporting here is for beyond what can be expected. Direct device access and forensics are in your future, as well as a frank discussion about your particular risks for the sorts of tools seemingly employed here.

if you’re having issues with your school or business login, contact the associated IT organization.

The whois for the surveysapple.com domain is registered to Apple Inc., and I have references here to that domain in messages from Apple going back over a decade, too.

Based on your own use of whois, you will of course know all that.

The rest of the images posted here are seemingly immaterial.

T3ddy19 wrote:

Well, I was the Security person installing a complete PKI system at a banking site. It involved creating key pairs for both the server and the client. So the client would have a private key for his part of the connection, and the clients public key was available to view the encrypted data. Likewise, in this scenario, the server had a public and private key as well. This is a very secure method of connectivity with key “exchange”. However, an SSL site may not always provide a key exchange. You will get a security certificate to view encrypted data, but a key pair exchange does not occur without the entire key pair exchange. I think Proton email provides this type of key exchange, but not all “ssl” sites. It can be a bit complicated. This info came from an ssl dot com site:

”Discussions of PKI will quickly lead to you SSL which require a private key and a public key. The private key is held on the web server. The public key is embedded in the SSL certificate. When you visit a website and you see that lock to the left of the address bar, and the URL says https, your browser will automatically download that public key along with the certificate, which confirms that the website is indeed who it presents itself to be.” This validates the site, but not the client. A key pair exchange is required to have a 2 way encrypted exchange with PKI key pairs, vs a single SSL web site. It’s been a while since I worked on this huge project. But while SSL and PKI are related, they are not the same thing. It is much easier to use SSL vs full PKI with 2 key pairs. It’s too much for this forum, but searching on PKI bs SSL provides lots of info about the differences.

The private keys are necessarily present on both ends of the connection.

For HTTPS, the end that is usually most interesting is the one on the server, and that private key and the signed public key are then used to check the signed public key against the trust store.

There are applications where the certificates on both ends of the connection are verified.

The private key doesn’t leave the client or leave the server, but the private key is necessarily involved in the challenge-response math.

The clever parts of PKE is how it doesn’t share the private keys present on each end, but does use it in the verification to “prove” its existence and correctness, and (when done right) sets up ephemeral keys to avoid cases where a subsequent breach of a private key allows previously-captured network connection data that used that key-pair to be decrypted. That would be bad. Oh, and how it uses math that’s easy to calculate in one direction, and hard in another; some operations are very difficult to reverse. The math underlying cryptographic hashes (digests) are also similarly one-way, but that’s fodder for another reply.

TLS inherently includes the handshake (this is the TLSv1.3 stuff) for the handshake), the key exchange, and establishing the session keys (those preferably being ephemeral), the certificate verification, and negotiates the connection encryption algorithm used, among other details, and only then lights up the lock icon.

If you’re creating key-pairs for that bank, that’s either a self-signed setup with key-pairs for each connection, or generating a private key and a certificate signing request. The CSR is then signed by either a commercial certificate vendor, or by whoever is administering the local organization's own private certificate authority. The commercial signing providers is how most websites work, in conjunction with certificate vendors and the trust stores implemented by most (though not all) operating system vendors. The private stuff works just fine—I have various of these running—but does need a trusted path to load the public key into the various clients.

I’ve written a fair amount of TLS code (in mostly C and C++, though with some Swift) (the Apple PKE and TLS frameworks are easier than libtls, and libtls APIs is easier than OpenSSL APIs, and there are others of differing complexities), and designed and worked on various apps and app server configurations in enterprise environments, as well as writing a whole lot of documentation for both TLS and ssh connections, and more than a little troubleshooting. And yes, TLS and ssh are different in numerous ways, but the PKE parts work the same.

Most folks glaze over when discussing TLS, of course. Usually with good reason. 🤪

part 1 of 2:

T3ddy19 wrote:

In answer to your question, no I have not. I looked up some of your keywords on Apple, and found a lot (even excess) of information, with links to more info, such as AAA certificate (it’s a valid cert per Apple).

It's one of the trusted root certificates shipped with Apple operating systems.

There are also reports of what is apparently a carrier app installing a related root certificate.

The current Cert number based on OS is also listed is Apple. Mine does not match but I don’t know why.

Trust stores are updated occasionally, and folks running older operating system versions will have older trust stores. Apple might patch an older operating system for a trust store issue, but that doesn't happen very often.

But I could not figure out what AAA is used for exactly it’s used for on Apple.

It's a root of trust for the certificates provided by the particular certificate authority. Which tells those unfamiliar with modern networking and with distributed authentication approximately nothing. Then if the discussion gets into the mathematics, the audience usually glazes over.

There was a mention of APIs, and other things related to push notifications, email and more.

Certificates are presented by users, by apps to servers, by web servers to web browsers, sometimes by web browsers to web servers, by printers including AirPrint printers, and by other stuff. Certificates are either self-signed, or are signed and can be traced back to some trusted root certificate. The trusted root certificates can be locally loaded (such as can happen via certain types of apps or via IT-provided certificate profiles), or the trust store can be pre-populated by the operating system provider, or the trust store can be provided by the server or client package provider depending on the details of the particular configuration.

We're getting into the "glazes over" part.

That did sound like developer info, but don’t take my word on this. The APIs per Apple appear to be related to push notifications, a few are listed.

Push notifications do use certificates, but so too does pretty much everything else these days.

I understand I can’t post links on here, so

I’d suggest searching Apple and include keywords. Some very technical people have responded such as MrHoffman and IdrisSeabright, they both have resolved many questions based on posted profile numbers. But no resolutions to date.

There is nothing to resolve here, as I've yet to see any indication of anything wrong here.

Curious, why do you think you are in developers?

Developers might use frameworks that use certificates, and some will generate or use or verify certificates directly in their code. Developers are not particularly relevant to certificates and certificate stores. If anything, system administrators and the folks establishing their own private trusted certificate chains will spend somewhat more time in this area. And Apple spends time here of course, as they provide many of the frameworks used, and provide the certificate stores.

I’ve heard that before and don’t know how to tell. If I ever find the answer, I will post it, provided it’s within guidelines. BTW, one of my Trust Store numbers start with 2022, per Apple site, it says IOS 17 should start with 2023? I have/had several devices, one is rather old, another purchased last year, both start with 2022.

That would usually mean an operating system version that arrived somewhat prior to 2023071300 is in use; a version released before July 13th, 2023. For operating systems released after that date, the current trust store version is 2023071300.

If any here are not already running iOS 17.1.2 or iPadOS 17.1.2 on a device capable of running iOS 17, time to update.

If you are running at least 17.1.2 and don't have that 2023071300 trust store (or a later version, if and as that becomes available), you can back up the device, factory reset the device to 17.1.2, and restore, and check again.

1/2

part 2 of 2

Those that have loaded carrier apps can have carrier-related certificates and carrier-related Wi-Fi details loaded, as well. Some discussion of that was posted earlier in this thread.

Background on asymmetric public-key cryptography:

... https://en.wikipedia.org/wiki/Public-key_cryptography

... https://en.wikipedia.org/wiki/Public_key_infrastructure

And as I posted earlier in this thread: a Khan Academy intro.

Some of my previous replies in this thread:

... Trust Store Version - Apple Community

... Trust Store Version - Apple Community

... Trust Store Version - Apple Community

... Trust Store Version - Apple Community

T3ddy19: What you have posted in your previous replies here can be inferred to indicate you are a target of an immensely sophisticated attack and related tooling worth millions of dollars—espionage-level exploit tooling—and far beyond the realm of what assistance can be rendered here, if what you have reported ("Although it sounds like Pegasus virus, it has a different name for this years version") can be corroborated. And that sort of digital forensics and that sort of corroboration just can't happen via forum postings. Reported security issues persistent and unresolved since 2021 —particularly those that persist past a factory reset and other recommendations—are not going to get addressed around here.

2/2

T3ddy19 wrote:

Still going on, finding out more however, and many similar attacks to gov as well.

Those users who are a negligible fraction of a billion or so devices in use, too; unusual or special cases.

If you are senior in government or major private organization, have access to sensitive or classified data, or access to great wealth, or a dissident or investigative journalist, or have personally annoyed somebody very rich, beat get assistance with your security. Assistance with your security which stretches well beyond iOS, too.

In general, follow what Apple suggests here: Personal Safety User Guide - Apple Support as well as running Safety Check, two-factor authentication, unique and robust passwords, keeping on current hardware and iOS, maybe Lockdown Mode, maybe add security tokens / security keys, and maintain an awareness of phishing and other common schemes and scams.