Jag har fått svar från Dan Holcomb, en av forskarna bakom den artikel där dom beskriver användning av SRAM för ID och slumptalsgenerering jag tidigare bloggat om. Dan svar på mina frågor ger svar på en del av saker jag tidigare tagit upp här på Kryptoblog. (Notera att jag taggat upp frågor och svar för att det skall bli lättare att följa med.)
(Q1) If you communicate the complete SRAM state, this implies that the external host get access to the the RNG sources supposedly to be used by the device for seeding device-internal cryptographic functions. Isn’t that a security problem?
(A1) Our intent is that a given block of SRAM would either be used for TRNG or else for ID, but never used for both on a given power-up. You are correct in observing that our random source would not be useful in TRNG if we transmit it as ID.
Här måste man alltså på något sätt komma på att hålla reda på vilka block i kretsens minne som skall användas för vad. Och hur skall kretsen veta vilka block den skall använda? Om den får order om att leverera ett givet block, hur vet den att det inte är ett av de block som bara skall användas som entropikälla och därmed inte skickas iväg?
(Q2) Have you consider low cost/low complexity methods for the device to determine if “long-enough” have passed? That is allowing the device to check if the SRAM have reached proper initial state, and if not take protective actions? (For example refusing to communicate with an external host.
(A2) We have not yet put much thought into how to prevent this, but do agree that this is an issue that really does need to be addressed.
Här behöver man alltså hitta teknik och metodik för att kontrollera tiden och hantera situationen när för kort tid passerat.
Sedan hade jag flera frågor som till viss del var relaterade till upprepad kommunikation av data, vilket det visade sig att dom inte gör:
(Q3) I didn’t see the info in the paper about this (I might have missed it): How many times do you need to extract the SRAM mem dump from the device (with power cycling and waiting “long-enough” in between) to perform device fingerprint template creation with reasobable accuracy?
(A3) The number of samples to create the template depends on how reliable the mem dump of the device is. We found that 3 was reasonable for creating a template, but using more dumps will result in a more accurate template. In fact, the matching can often be done based on a template created from just a single memory dump, with no averaging at all.
(Q4) How many times do you need to extract the SRAM mem dump from the device (with power cycling and waiting “long-enough” in between) to perform fingerprint device matching (i.e to identify a known device) with reasobable accuracy?
(A4) Once the template is created, the matching is performed based on a single fingerprint collected in the field (a latent print). The averaging is only applied when creating the template (a known print).
(S5) If the complete state is communicatied (x number of times) to get the device ID, given the use of similar communication means as other low cost RFID devices (passiv, back scatter) your method would at least take much longer time, correct? For example 256 Bytes * x dumps vs 4-8 Bytes for stored device ID.
(A5) Only one dump is transmitted. But still it takes longer: with each bit of SRAM providing less identifying ability than EEPROM, a greater number of bits (compared to EEPROM) must be transmitted.
Mao är det vid matchning mycket mindre data som behöver skickas än jag först misstänkte – vilket är bra. Däremot verkar dom använda begreppet latenta fingeravtryck på ett något märkligt sätt. Det dom gör en matchning med en kandidat. Nåja, tillbaka till frågor och svar:
(Q6) Have you looked at the amortized cost of identifying the device though its lifetime using your FERNs technology vs adding (E)PROM/fuses to the device (with additional device and manufacturing cost)? This might be hard to do, but would be interesting to see.
(A6) We have not analyzed this. The EEPROM cells are smaller than RAM cells, but the process costs are higher, and the charge pump adds area overhead. The advantage of using SRAM is that it doesn’t need to be added specifically for our purposes and can be used as general purpose memory.
(S7) Have you considered the change in device identification/authentication protocols your scheme causes? As I understand it, the device doen’t know it’s ID (you stated as much in a previous response), instead it has to rely on an external host to establish the identity. How does this affect things like challenge/response protocols? Any security implications of this?
(A7) When I said that the device doesn’t know its ID, i meant only that it doesn’t need to be programmed to have its ID. In other words, it doesn’t have any recollection of its ID in non-volatile storage. It still contains the ID whenever it is powered on, so it is exactly analogous to how EEPROM always contains its ID. The only difference is that the ID is not fully reliable.
Om jag fattat det rätt pratar alltså Dan om det ID som den externa läsaren tar fram och sedan överlämnar till kretsen, och Dan ser inte att det ändrar förutsättningarna för ID:t.
Jag har skickat några följdfrågor, men jag är rädd för att jag böjar bli jobbig och inte får fler svar… 😉
