I suggest you read the iOS Security Guide: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
I cannot find documentation to verify this. I presume the people down voting you do, but unfortunately they've chosen to down vote instead of being useful and posting a link. (The only link I've seen is for A7 and later systems)
The PIN number is entangled with the device's 256-bit "UID", which itself is on-die in the SoC/CPU and NOT extractable without either being able to run code on the CPU, or decapping the SoC, reverse engineering its implementation, and extracting the UID, all from the SEM imagery.
The PIN number and the UID are fed to key derivation code for strengthening; the result of that process is used to actually perform encryption of the data on the NAND.
The weak point here is the PIN number; the FBI would be extremely hard-pressed to brute force the derived AES keys.
This is described in the "Tangling" definition on page 59 of the iOS Security Guide: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
I flagged the article, as the entire argument is predicated on a factually false premise.
Even if he's wrong, the reason why he's wrong is informative.
It's possible that I'm wrong, but not for the reasons given so far. Once you have a copy of the flash you can always get back to the current state by installing a copy of the flash in its current state. Then you can simply brute-force the PIN.
If you modify the kernel on the NAND, signature checks in the on-die bootloader will fail, and you won't get to run.
If you modify application binaries on the NAND, signature checks in the signed kernel will fail, and you won't get to run.
The flash in question is a BGA part on a high density double sided board. It definitely would be hard to desolder the flash without desoldering anything else nearby (as a bonus, the CPU is directly on the other side of the PCB). Specialized machines exist for doing this, but require a highly skilled operator.
They want something they can plug the phone into so they can give every site one and not send it out to a expensive technician for modification and data extraction.
That's true. But come on, this is the FBI we're talking about.
> They want something they can plug the phone into so they can give every site one and not send it out to a expensive technician for modification and data extraction.
Yes, of course that is what they want. That is the whole point.
If they were not opposite each other, then the following approaches to spying on or tampering with the system would be possible:
• Cut the write signal between the CPU and the flash so that the CPU cannot erase anything in the flash.
• Cut all the control, data, and address lines between the CPU and the flash and insert a man-in-the-middle device that can allow or block CPU access to the flash and that can read/write the flash itself.
They point at the NAND chip and just say "pull off the encryption key, then decrypt the device" but without supplying any fact as to how the key was stored in the iPhone 5S, what kind of resources reversing it would take, and if Apple has employed any kind of anti-reverse engineering means.
For all we know Apple could have thrown different elements of the decryption key all over the device, the A7, the NAND, and elsewhere. Without more technical specifics it is hard to draw the conclusion this article draws.
What say you about my overarching point about the technicals of key extraction and decryption? Do you have any information on more specifics? I am not calling you wrong, I am saying you aren't showing us enough specifics to say you're right.
I wish this was the point made by more mainstream media outlets. Not for the reasons the article author posts, but rather that the SOP for Apple devices involves bringing it to a known access point and powering the phone to allow an iCloud backup to occur.
Additionally, had they brought the device to a known access point and plugged it in to a charger, they could have availed themselves of another handy thing: Access to a computer synchronized with iCloud would've yielded an iCloud-specific token that could be used to download and extract the backup (without Apple's involvement), bypassing even TFA. 
The article is interesting, but it presents a hypotheses with far more confidence than it deserves. People finding the article, and not this discussion, will be misled.