STM32 Unique Device ID: Zufällig oder vorhersagbar?

[Johannes O. (jojo_2)]

Hallo zusammen,

ich hab hier einen STM32F411.
Ich lese die "Unique Device ID" aus, um den Mikrocontroller eindeutig 
identifizieren zu können.

Zusätzlich schreibt das Datenblatt:
> for use as security keys in order to increase the security of code in
> Flash memory while
> using and combining this unique ID with software cryptographic
> primitives and
> protocols before programming the internal Flash memory

Hört sich ja toll an, die schlagen da direkt vor, diese ID auch als 
Key/Schlüssel zu verwenden. Da es auch noch 96 Bit sind, wäre das sehr 
verlockend.

Allerdings habe ich das Gefühl, dass diese ID zwar "einmalig" ist, aber 
keinesfalls "zufällig" ist bzw. die Bitwerte "gleichverteilt".

So ist beispielsweise bei meinem Chip:
0x00590035  0x31345106  0x38303834
- Keinerlei Halbbytes mit A bis F
- Drittes Word enthält nur Hex-codierte Zahlen (0x30-0x39 = '0' bis '9')
- usw...

Vermutlich enhalten diese Bits also nur sehr wenig Entropie...

Also habe ich mich mal auf die Suche begeben:

http://www.st.com/st-web-ui/static/active/en/resource/training/technical/product_training/STM32L4_System_eSign.pdf
Oh... Also dort steht nur die Position auf dem Wafer+Lot drin? Genauere 
Infos finde ich nicht, es heißt nur, dass es "on request" verfügbar 
wäre... Na damit kann ich erstmal nicht arbeiten.

Auch anderen ist dies schon aufgefallen:
http://false.ekta.is/2012/06/stm32-device-electronic-signature-unique-device-id-register/

(Background: Wenn die Unique IDs sich zu ähnlich sind, ist der Schlüssel 
effektiv sehr schwach. Gleiches gilt, wenn es sich um Waferkoordinaten 
handelt, da diese nur einen bestimmten Range einnehmen können (und 
außerdem X und Y Koordinaten korrelieren (Mitte wahrscheinlicher als 
Randgebiete, da dort die Ausfälle eher zunehmen!) . Außerdem sind die 
inkrementell. Wenn man weiß, wie die ID aufgebaut ist, lässt sich 
eventuell das komplette Produktionsvolumen einfach Brute-Forcen.)


Weiß jemand genauer, was es damit so auf sich hat? Gibt es 
Erfahrungswerte?
Ansonsten würde ich ST mal anschreiben, allerdings befürchte ich, dass 
sie mir da kaum Infos geben wollen als Bastler...

[Jim M. (turboj)]

Johannes O. schrieb:
> Vermutlich enhalten diese Bits also nur sehr wenig Entropie...

Das wäre auch zu erwarten, da der Hersteller so keine Datenbank mit 
schon vergebenen UIDs führen muss.

Wenn man daraus einen Crypto Key basteln möchte, sollte man das mit 
einem Salt hashen, also MD5(Salt+ UID) oder SHA1(Salt+UID). Solange ein 
Angreifer den Salt nicht hat nützt ihm dann das Wissen über die UID 
herzlich wenig.

[Nils P. (torus)]

Was Jim sagt.

Wenn Du zusätzlich während der Produktion den Hash digital signierst, 
dann kannst Du auch überprüfen, ob der Hash von Dir erzeugt wurde oder 
ob Dir jemand Zufallsdaten unterjubeln möchte.

Eine kleine ECDSA Implementation ist so aufwendig nicht.

Das am Anfang des Prozesses wenig Entropie vorhanden war spielt dann 
keine Rolle mehr.

[Johannes O. (jojo_2)]

Danke für eure Antworten, das bestätigt dann meinen ersten Eindruck: Ich 
muss noch mehr "außenherum" dazubauen, um dieses Feature wirklich sicher 
benutzen zu können.
Da ist das Datenblatt auch mal wieder sehr optimistisch gewesen mit 
ihrem "use as security key[s]"... Schade...