EPROM an Mikrocontroller STM32F103 (3.3V)

Serielle EEPROMS gibts für die Spannung

http://cdn-reichelt.de/documents/datenblatt/A300/MIC_11AA02E64.pdf

Oder willst du wirklich ein UV löschbares EPROM verbauen ?

Gruß JackFrost

TImo schrieb:
> ich möchte ein Eprom an meinen STM23f103 Mikrocontroller anschließen und
> anschließend Lesen und Programmieren.

Willst Du Dir einen Eprom-Programmierer selbstbauen?

Wozu soll das gut sein? EPROMs sind Technik des letzten Jahrtausends, 
heute nimmt man Flash-ROMs, die brauchen keine abstrus hohen 
Programmierspannungen und können vor allem ohne ausgebaut zu werden auch 
wieder gelöscht werden.

Mit gigantischer Kapazität gibt es Flash-ROMs spottbillig in Form von 
SD-Karten.

Für STM32 F100 gibt auch ein "EEPROM" SW um in das Flash zu schreiben. 
Schreib cyclen sind dan begrenzt auf ca 10 k, aber mit wear leveling kan 
das verbesseren. Nachteil : um das flash zu wischen, muss minimal ein 
page gewischt werden, damit braucht man immer das dobbel von "eeprom" 
memory.

Und wenn du das EEPROM 
http://www.atmel.com/Images/Atmel-5228-SEEPROM-AT25080B-160B-Datasheet.pdf#page10

"Extern" programierst und dann CS und WP zusammen legst. Ggf unter dem 
IC dann kann man ohne Zugriff nicht schreiben

Gruß JackFrost

TImo schrieb:
> Ich brauche eine Art OTP Speicher.

Hmm. Und mit welcher Kapazität? EPROMs sind halt nicht besonders groß.

Wobei, wenn Du Dir eins mit 25V Programmierspannung ausgesucht hast, 
dann kommts Dir nicht auf Größe an, das ist nämlich uralt. "Neuere" 
EPROMs kommen mit 12.5V aus ...

Allerdings:

Die Daten in EPROMs sind nicht vor dem Überschreiben gelöscht; Du kannst 
jedes EPROM mit Nullen überschreiben. Nur Einsen bekommst Du nicht ohne 
externes Löschgerät wieder hinein.

Als Sicherheitsmechanismus taugt das also nicht sehr viel.

TImo schrieb:
> Aber gibt es
> nicht ein Speicher der NUR geschrieben und nicht gelöscht werden kann??

TImo schrieb:
> Es muss zeit zur Zeit Datten geschrieben werden. Das heißt es muss eine
> Möglichkeit gefunden werden das alles vom Mikrocontroller gesteuert
> wird.

Schließt sich das nicht gegenseitig aus ? Oder willst du nur Anhängen ?

Willst du das fertigen lassen ? Wenn ja , kannst es ja bei beidem mit 
BGA probieren und die /WP Leitung als Zwischenlage einer 
Multilayerplatine. Ist die Frage wie weit das stört wenn die auf dem GND 
Layer liegt.

Gruß JackFrost

TImo schrieb:
> Aber gibt es nicht ein Speicher der NUR geschrieben und nicht gelöscht
> werden kann??

Nicht als Halbleiterspeicher. Als optischer Massenspeicher, da heißt das 
dann WORM ("write once read many"), oder als Bandlaufwerk (bei LTO gibt 
es für diese Aufgabe spezielle Bandtypen).

Aber das ist nichts, um es mit einem µC zu verbinden.

Spezifiziere Deine Aufgabenstellung genauer. Wenn es um 
Manipulationssicherheit geht, sollte eine stinknormale SD-Karte genügen, 
auf der Du Dateien ablegst, die wie z.B. bei PGP mit einem Schlüssel 
gekennzeichnet sind. Dann können die Dateien zwar gelöscht, aber nicht 
verändert werden.

Schau, ob das hier nicht funktionieren würde:

https://www.maximintegrated.com/en/products/digital/memory-products/DS2505.html

fchk

Die Spec klingt, als ob jemand den TÜV im Hause hatte, ohne selbst einen 
kompetenten Elektroniker zugezogen zu haben. Macht nix, sowas führt 
manchmal zu interessanten Aufträgen. ;)

Scherz beiseite, wie wäre es, das EPROM mit einem zweiten 
Mikrocontroller zu emulieren? Eine MCU die Ihren eigenen Flash-Speicher 
schreiben kann, sowie entsprechend aktivierten Firmwareschutzmaßnahmen, 
löst die Aufgabe.
An einen F1 würde ich einen F0 hängen - selbe Entwicklungsumgebung, 
Hardwarekosten 0,50€.

Meine bevorzugte Lösung wäre die interne EEPROM Emulation gewesen.

Weiteres Aufwand rechtfertigt die bisher bekannte Aufgabenstellung 
nicht.

Wenn Du irgendwas sinnvoll schützen willst, solltest Du erstmal mit 
einer Bedrohungsanalyse starten bevor Du Dir über Gedanken über die 
Umsetzung oder konkrete Technologien wie EPROM machst.

Mal ein paar Fragen dazu als Anregung:

Also was willst Du vor wem/was schützen?

Geht es um einen böswilligen, aktiven Angreifer oder um Schutz vor 
Fehlern, Störungen etc.?

Wenn Angreifer:

Wie ist der Angreifer ausgestattet?

Was hat er für Zugriffsmöglichkeiten und wie lange?

Reicht es, einen Angriff als solchen zu erkennen oder muss der irgendwie 
verhindert werden? Was soll dann passieren?

Was für ein Schaden tritt ein, wenn der Angreifer den Schutz überwindet?
Lohnt sich da ein aufwendiger Schutz überhaupt?

Oder tritt ein singifikanter Schaden erst auf, wenn eine fertige 
Angriffsanleitung irgendwo publiziert und dann massenhaft nachgemacht 
wird?

Was für ein Schaden tritt ein, wenn die Schutzfunktion fälschlicherweise 
einen Angriff erkennt (false-positive)?

Oder geht es eigentlich gar nicht darum einen wirklich sinnvollen Schutz 
zu entwickeln, sondern es muss nur irgendeine 
Vorschrift/Zertifikat/Norm... mit geringstmöglichem Aufwand eingehalten 
werden?

Andere STM32 als der F103 haben auch etwas OTP on chip...

eagle user schrieb:
> Warum einen zweiten uC? Das kann der erste doch selbst?
Warum reißt Du meinen Post auseinander, wenn Du schon zitierst?
Ich schrieb bereits "Meine bevorzugte Lösung wäre die interne EEPROM 
Emulation gewesen."

TImo schrieb:
> Also die Lösung scheint ein Password-Ptotected Flash memory.
>
> http://www.spansion.com/Support/Datasheets/S25FS-S_00.pdf
>
> würde aber gerne eine mit 3,3 V haben.
>
> Kennt jemand so eine Flash Memory Typ mit 3.3 V ??

Nimm eine Anzahl 74LVC1T45. Das löst Dein Problem.

fchk

Ich fänd es wichtig, wenn zunächst mal Gerds Punkte abgearbeitet werden, 
bevor weiter wild Spekulationslösungen gemacht werden.


Gruß

Jobst

TImo schrieb:
> http://www.spansion.com/Support/Datasheets/S25FL127S_00.pdf
> Dieser Flash-Memory erlaubt "– Advanced Sector Protection (ASP)
> – Individual sector protection controlled by boot code or password".
>
> Das heißt bei mir wird schreiben und lesen ist nur mit einem gültigen
> Password möglich sein.

Nun, SPI ist keine Geheim-Schnittstelle. Jeder billige Logic-Analyzer 
für 10 EUR kann Deinen SPI-Datenverkehr aufzeichnen und damit das 
Passwort mitschneiden wenn Du es an den Flashbaustein überträgst.

Ich bin immer noch der Meinung daß Du erst mal ne gründliche 
Bedrohungsanalyse machen solltest.

Gerd E. schrieb:
> Ich bin immer noch der Meinung daß Du erst mal ne gründliche
> Bedrohungsanalyse machen solltest.

Ich auch. Will er aber wohl nicht. Ihm reicht, wenn 'sicher' oben auf 
dem Baustein drauf steht.

Gruß

Jobst

Gerd E. schrieb:
> Nun, SPI ist keine Geheim-Schnittstelle. Jeder billige Logic-Analyzer
> für 10 EUR kann Deinen SPI-Datenverkehr aufzeichnen und damit das
> Passwort mitschneiden wenn Du es an den Flashbaustein überträgst.
Das Problem haben FPGAs ja schon immer. Die dazu passende Lösung ist, 
dass auf der SPI kein Klartext übertragen wird.
Naja, ist doch eine schöne Sammlung geworden, was man so an 
Parameterspeicher an MCUs hängen kann.

Marcus H. schrieb:
> Das Problem haben FPGAs ja schon immer. Die dazu passende Lösung ist,
> dass auf der SPI kein Klartext übertragen wird.

Naja, die Kommunikation ist schon Klartext, nur die Daten nicht.
Und auch hier stellt sich die Frage, was erreicht werden soll.
Die Daten im EEProm lassen sich: Kopieren (!), Löschen und -wenn auch 
nicht sinnvoll- überschreiben.

Der einzige Angriff, der damit abgewehrt wird, ist reverse engeneering 
des Code. (Und auch da bin ich sicher, dass es da Möglichkeiten gibt, 
solange der 'Encoder' zur Verfügung steht.)


Gruß

Jobst

Jobst M. schrieb:
> Marcus H. schrieb:
>> Das Problem haben FPGAs ja schon immer. Die dazu passende Lösung ist,
>> dass auf der SPI kein Klartext übertragen wird.
>
> Naja, die Kommunikation ist schon Klartext, nur die Daten nicht.
mmh?

> Und auch hier stellt sich die Frage, was erreicht werden soll.
> Die Daten im EEProm lassen sich: Kopieren (!), Löschen und -wenn auch
> nicht sinnvoll- überschreiben.
Ganz so einfach ist das Kopieren nicht. Aktuelle Chips haben eine 
eindeutige ID. Ein ordentlicher Scrambler baut auf sowas auf.

Marcus H. schrieb:
> Ganz so einfach ist das Kopieren nicht. Aktuelle Chips haben eine
> eindeutige ID. Ein ordentlicher Scrambler baut auf sowas auf.

Und in der Massenproduktion werden dann in jedem Chip andere Daten 
abgelegt?
Und auch die ID ist ja lesbar und somit kopierbar (mit etwas mehr 
Aufwand - zugegeben)


Gruß

Jobst

Jobst M. schrieb:
> Und in der Massenproduktion werden dann in jedem Chip andere Daten
> abgelegt?
Mich überrascht, dass Dich das überrascht.
Was für MCUs und FPGAs setzt Du denn so ein, dass Du das nicht kennst?

Ich habe mir bei Devices mit externem, seriellem EEProm noch nie 
Gedanken darüber gemacht. Dass die Daten verschlüsselt sind, war mir 
bekannt, auf welche Weise, nicht.


Gruß

Jobst

Schau dir mal die Atmel AT45DB011D an.
Ist ein seielles Flash mit einer Funktion Namens Sector Lockdown.
Wenn du dieses Register setzt, kann es nie wieder zurück gesetzt werden 
und es verhindert das Programmieren des entsprechenden Sektors des 
Speichers, somit hast du ein EPROM.

Christian_RX7

PROM... ;)

Der unerreicht sicherste Speicher ist immer noch das "Signetics 25120".

Für aktuelle, generische Anwendungen sind "Atmel CryptoMemory" eine 
Idee:
http://www.atmel.com/products/security-ics/secure-memory/default.aspx

Marcus H. schrieb:
> Der unerreicht sicherste Speicher ist immer noch das "Signetics 25120".

Brilliant finde ich im DB neben dem Wasserhahn noch das Diagramm mit den 
Steckzyklen und den zu erwartenden verbogenen Beinchen :-D


Gruß

Jobst

Jobst M. schrieb:
> Und in der Massenproduktion werden dann in jedem Chip andere Daten
> abgelegt?
Wieder näher am Thema und warum ich die EEPROM-Emulation mit eigener 
Firmware bevorzuge ->
Max max hat hier auch auf die harte Tour rausgefunden, wie gut moderne 
Schutzmechanismen arbeiten:
Beitrag "Re: STM32 ST-LINK Utility Read Out Protection to level 2"

Es ist nicht unmöglich an der höchsten Schutzstufe einer aktuellen MCU 
vorbeizukommen, es braucht aber etwas mehr Equipment und Erfahrung.

Marcus H. schrieb:
> Es ist nicht unmöglich an der höchsten Schutzstufe einer aktuellen MCU
> vorbeizukommen, es braucht aber etwas mehr Equipment und Erfahrung.

Wenn einem dieser Schutz nicht reicht, sollte man evtl. über eine 
ähnliche Lösung wie bei den IBM-Cryptokarten nachdenken: Wenn die feinen 
in der Vergussmasse liegenden Drähtchen berührt, durchtrennt oder 
verbunden werden, wird der batteriegepufferte Speicher gelöscht.


Gruß

Jobst