Most likely it's a fuse type thing. It literally is a one time programmable fuse that is set by some subroutine. Basically you execute that function and bam you get back some key that says that it worked. You try to execute again and the fuses have already been set and the key is the same. Many ICs have built in one time programmable memories or fuses to be used during provisioning. Such as to set a MAC address on a Ethernet chip or wifi chip. It's literally burned into the chip in the factory and cannot be changed. It's a one time thing and does not change after reboot or anything.

In chip manufacturing, there's a way to make a "random" pattern on a chip, unknown even to the manufacturer. So a part of the SoC is random, but can be read by other parts. That becomes the random ID.

Imagine it like taking that piece of paper to give lottery numbers, throwing a couple darts on it, and then using that as the ID. Except the dart throwing happens in a way where you can't actually control/see the result during manufacturing.

There's a term for this that eludes me.

I'm curious what this process would be. My understanding was they'd typically have a small section of write-once fuses/PROM, and then some final process step to permanently program an ID into that area. That would mean the process to do so could possibly be recorded (or compromised), so I'm interested if there's a fabrication technique to reliably create random ROM sections.

Do you have any more info?

https://en.m.wikipedia.org/wiki/Physical_unclonable_function it's called a physically unclonable function.

The page is a bit obtuse, honestly I might have misunderstood a part of it.

I kind of doubt they would use some process like this for the iPhone, they probably program it in to avoid ID collisions. Yea I'm also curious if there is some name for this scheme where it generates some random pattern, I haven't heard of it myself and I previously worked in the semiconductor device world. Not saying it doesn't exist, just haven't heard of it. There are plenty of random sources that are used to generate a random bit such as thermal noise or clock jitter etc, but that is a single bit that you would then need a circuit to read that bit over and over to generate a random string like a UUID, and you would need some sort of statistics that would prove that that UUID that you generate over a finite time (probably a few milliseconds) is not highly self-correlated.

The UID is 256-bit. With a proper random number generator you don't do anything additional to avoid collisions. Hardware random number generators are standard for crypto processors like the secure enclave and there are standard tests used to test the output of a RNG for problems like the one you're talking about (e.g. the NIST test suite).

Stochastic process perhaps?