I have read in many places that SRAM PUF is considered a weak PUF, since it generates a single response (based on the value of all RAM cells upon power-up).
Why can't I use just a limited number of bytes from the RAM space in order to create a CRP? For example if I have a 64kB RAM, I can divide it into 256 sections, each section 256B long, obtaining 256 CRP's? (Assuming that all the RAM cells are stable and can be used for PUF...)
In the article, "weak PUFs" are for key storage, and "strong PUFs" are for authentication, but both are PUFs. It's just a function of how you use them. A 32-bit PUF is just a random 32-bit number. What makes a weak PUF strong is pairing it with an HMAC circuit, or something for a challenge response.
A few notes on the article: the assumption that EEPROMs are expensive in both power and area is not really true. It's difficult to find any IC without some sort method to hold the serial number, and if it is not EEPROMs, it's e-fuses (eFUSE, antifuse). Everything in IoT has some sort of method to program memory. To that end, if I have EEPROM infrastructure already, PUFs cost more regarding area, and both circuits have the same issues when I de-cap something and put my probes on it. The circuit discussion was rather weak and some of the implementation examples in the overview won't work on aggressive nodes.
Strong SRAM PUFs exist, and this is the way a strong PUF device is designed. The challenge (for response) is the access pattern. SRAM tends to be contiguous, so partitioning into CRPs can be easy if the dependability of the silicon is good. This may not always be the case as it is die /family dependent. So you can segment your 64KB into say two units. The "weak" nomenclature may be a throwback to days of smaller RAM sizes, and making an allowance for the following...
You cannot say "Assuming that all the RAM cells are stable and can be used for PUF". RAM cells are definitely not stable, and repeatable behaviour is fundamental to the PUF concept. Otherwise the SRAM forms an entropy source for random number generators. This variability may be as high as 1 bit /byte on some INFINEON TRICOREs (source). You are balancing predictable states against unpredictable ones.
Your idea of 256 bytes may be too low for a sufficient number of reliable bits to be extracted. Error correction is an absolute must and cannot be overlooked otherwise the whole PUF concept fails. SHA256ing blocks of 32 bytes will not work. Quantum, voltage, temporal and thermal effects will ensure that the hash will not produce consistent output. Memory-based Combination PUFs for Device Authentication in Embedded Systems shows this effect ameliorated via error correction using 16 such blocks. There is a white paper here that needs 1KB of cells to get 256 reliable bits. That's a 32:1 ratio.
So it might work if you pick /screen your silicon carefully, but it's hard to say without actually trying it. Die variability is too high to speculate on 256 bytes, but the concept is valid.
PS. The number of challenges can be the permutation of CRP cells, not just a single response from each individual cell. That's illustrated in Open-Source Software-Based SRAM-PUF for Secure Data and Key Storage Using Off-The-Shelf SRAM. There they create a possible $10^{12,626}$ pairs, using a Arduino Mega 2560 and COTS SRAM.
