Mahlzeit! Benutzt hier jemand die 96-Bit-UID der STM32-Familie? Die würde sich ja als Geräte-Seriennummer anbieten. Aus der Kryptografie-Ecke hört man, dass man alle 96 Bits nutzen muss, damit sie eindeutig bleibt. Dass effektiv viel weniger Bits drin stecken, wäre für eine Seriennummer ja nicht schlimm -- außer, jemand muss sie auf einen Zettel schreiben und am Telefon vorlesen. Einfach als Hex wären das 24 Zeichen, aber immerhin unverwechselbare. Wenn die Nummer kürzer werden soll, muss man aufpassen, weil 0 und O immer verwechselt oder am Anfang weggelassen werden. Klein- und Großbuchstaben sind mühsam auszusprechen. Bleiben noch :+*! um auf 41 verschiedene zu kommen. Damit könnte man drei Gruppen zu je 6 Zeichen verwenden. Gruppen sind immer gut und man braucht auf dem uC nur eine 32-Bit-Division. Dann fehlt noch eine Prüfziffer - ein ganz eigenes Thema... Für Steckerpins gibt es eine Art Standard-Alphabet, indem verwechselbare Buchstaben wie OIJ nicht vorkommen. Gibt es sowas mit einem etwas größeren Zeichenvorrat? Wie macht man das richtig?
Nun du legst dir ein Alphabet an mit z.B mit 5 Bit, dann codierst du jeweils 5 Bit mit deinem Alphabet und shiftest diese Bits dann aus deiner Quelle raus. Das geht natürlich auch mit 4 Bit oder 6 Bit. Sehr viele Freischaltcodes basieren auf solchen Verfahren
Bauform B. schrieb: > Benutzt hier jemand die 96-Bit-UID der STM32-Familie? Die würde sich ja > als Geräte-Seriennummer anbieten. Aus der Kryptografie-Ecke hört man, > dass man alle 96 Bits nutzen muss, damit sie eindeutig bleibt. Es ist etwas länger her dass ich da rein geschaut habe. Ganz so einfach war das mit der Seriennummer und Kryptografie nicht. Wenn ich das noch richtig im Kopf habe, dann sind in der Seriennummer bekannte Informationen wie der Typ encoded. Ich habe auch im Kopf, dass die x-y-Position des Chips auf dem Wafer in der Seriennummer kodiert ist. Das schränkt den Wertebereich der Seriennummer ein. Kram dich mal durch die Doku von ST. > Wie macht man das richtig? Richtig gibt es nicht. Irgendwie muss der Informationsgehalt von 96-Bit kodiert werden. Manche Gruppen von Personen kommen mit manchen Systemen besser oder schlechter zurecht. Es gibt z.B. immer wieder Ansätze wie man Base64, Base32, usw. sicherer/besser lesbar machen kann. Dann gibt es seit einiger Zeit Verfahren bei dem Wörter verwendet werden. Da kommen merkwürdige Phrasen raus. Ich glaube die PGP Word List https://en.wikipedia.org/wiki/PGP_word_list war einer der ersten Listen für solche Fälle (8 Bits pro Wort). S/KEY verwendet eine andere Liste in RFC2289 https://tools.ietf.org/html/rfc2289#page-4-19 (11 Bits pro Wort). Es gibt sicher noch andere. Das heißt, mit der S/KEY Liste brauchst du mindestens 9 Wörter, mit der PGP-Liste 12. Eher mehr, wenn du eine Checksumme einbaust. Ob deine Benutzer dann in der Lage sind die Wörter richtig zu übertragen ...
:
Bearbeitet durch User
Hannes J. schrieb: > Wenn ich das noch richtig im Kopf habe, dann sind in der > Seriennummer bekannte Informationen wie der Typ encoded. > Ich habe auch im Kopf, dass die x-y-Position des Chips auf > dem Wafer in der Seriennummer kodiert ist. So ganz pauschal ist das richtig, aber... > Kram dich mal durch die Doku von ST. Das war jetzt ein spannendes Abenteuer mit eindeutigem Ergebnis: Aussichtslos. ST hätte sich den Random Number Generator sparen können. Anfangs dachte ich, es ist nur schlecht dokumentiert, aber immer gleich implementiert (vielleicht bis auf die allerersten Chips) -- bis ich die RM0376 und RM0377 gelesen hatte. Bei den L031, L032 und verwandten steht die x-y-Position nicht im ersten Wort, sondern hinter den anderen beiden, mit etwas ABSTAND (0x1FF8 0050, 0054, 0064). Na gut, ein Tippfehler in zwei Manuals, Copy+Paste. Die Manuals werden aber durchaus nicht einfach per Copy+Paste erzeugt, das Flash Size Register heißt mal F_ID, F_SIZE oder auch FLASH_SIZE, da ist UID vs. U_ID schon langweilig. Noch besser: das RM0454 erwähnt die UID-Register garnicht während sie im RM444 ausführlich beschrieben sind. Beide RM gelten aber für das gleiche Silizium (IDCODE 0x460 und 0x466). Alternativ hätten verschiedene Chips den gleichen IDCODE; das will ich nun wirklich nicht glauben. >> Wie macht man das richtig? > Dann gibt es seit einiger Zeit Verfahren bei dem Wörter verwendet > werden. Da kommen merkwürdige Phrasen raus. Ich glaube die PGP Word List > https://en.wikipedia.org/wiki/PGP_word_list war einer der ersten Listen > für solche Fälle (8 Bits pro Wort). S/KEY verwendet eine andere Liste in > RFC2289 https://tools.ietf.org/html/rfc2289#page-4-19 (11 Bits pro > Wort). Es gibt sicher noch andere. Cool! Aber irgendwie geht das in die falsche Richtung... > Ob deine Benutzer dann in der Lage sind die Wörter > richtig zu übertragen ... Der Fehler ist ja eigentlich das Loch in der Maschinenlesbarkeit. Jedes Telefon kann QR-Code lesen und hat Internet, warum denke ich immer noch an Papier und Bleistift?
Bauform B. schrieb: > Noch besser: das RM0454 erwähnt die UID-Register garnicht während sie im > RM444 ausführlich beschrieben sind. Beide RM gelten aber für das gleiche > Silizium (IDCODE 0x460 und 0x466). Alternativ hätten verschiedene Chips > den gleichen IDCODE; das will ich nun wirklich nicht glauben. Die G0x0 (mit dem RM0454) haben (soweit ich das an ein paar realen Exemplaren überprüft habe) aber dennoch die gesamte Peripherie der entsprechenden G0x1. Die Chips sind tatsächlich identisch, nur dass bei den G0x0 halt ein Teil eventuell nicht uneingeschränkt funktionsfähig ist. Sogar TS_CAL2 ist mit sinnvollen Werten im Flash drin, ebenso die UID. Allerdings waren bei einigen G0x0 in X- und Y-Koordinaten teilweise keine gültigen BCD-Ziffern, während ich das bei den G0x1 nicht gesehen habe. Kann natürlich sein, dass das ein Fehler im RM ist und nicht wirklich BCD gemeint ist ... Aber unabhängig davon: Der OTP-Bereich ist sicher die sinnvollere Alternative. Gibt's bei den meisten STM32.
A. B. schrieb: > Allerdings waren bei einigen G0x0 in X- und Y-Koordinaten teilweise > keine gültigen BCD-Ziffern, während ich das bei den G0x1 nicht gesehen > habe. Kann natürlich sein, dass das ein Fehler im RM ist und nicht > wirklich BCD gemeint ist ... Bei anderen Chips steht nur X & Y im Manual, aber ohne BCD dabei. Bei noch anderen steht nur "32 Bit" oder garnichts. Nichts ist unmöglich :) > Der OTP-Bereich ist sicher die sinnvollere > Alternative. Gibt's bei den meisten STM32. Bei einem L4 mit den 2K-Pages würde ich auch das normale Flash benutzen, ist ja für einen guten Zweck ;) Aber die eingebaute Seriennummer spart die ganze Verwaltung; von wegen eindeutig...
Thomas Z. schrieb: > Nun du legst dir ein Alphabet an mit z.B mit 5 Bit, dann codierst > du jeweils 5 Bit mit deinem Alphabet und shiftest diese Bits dann aus > deiner Quelle raus. Das könnte dann z.B. 3FY7 AA8C VE44 1234 Z575 lauten. Theoretisch liefern 0-9 und A-Z zusammen 36 Codes. Ein paar Verwechslungskandidaten solltest du aber berücksichtigen: F/S am klassischen Telefon 1/I 0/O Z/2 B/W M/N R/L in manchen asiatischen Sprachen Ja, das ist nicht trivial. Irgendwas mit 4,5 Bit je Symbol wäre vermutlich optimal (d.h. zwei Symbole kodieren jeweils 9 Bit, gibt halt eine große Lookup Table mit 512 Einträgen). Dann wären mit 22 Symbolen noch 3 Bit für eine Checksumme übrig. Oder du jagst die UUID durch einen Hash (MD5 oder so) und hoffst, nie eine Kollision zu bekommen. Dann musst du nur noch 16 oder 32 Bit kodieren.
Max G. schrieb: > F/S am klassischen Telefon > 1/I > 0/O > Z/2 > B/W > M/N > R/L in manchen asiatischen Sprachen ja, das hatte ich befürchtet, dankeschön. Aber ich glaube, es reicht ganz knapp für 5 Bit, ich lasse nur F/S, 1/I, 0/O und Z/2 aus. Wie gesagt, es ist ja maschinenlesbar, das muss man besser nutzen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.