Vorstellung der M5Stack ID-Unit: Krypto-Modul mit ATECC608B Krypto-Chip

In einen vorhergehenden Artikel hatte ich ja den M5Stack Atom Lite selbst vorgestellt. Dort habe ich erklärt, dass er auf dem ESP32-PICO-D4 basiert und das Pinout beschrieben. Außerdem bin ich auf den Knopf, den I2C-Port, den SPI-Port, und die interne RGB-LED eingegangen.

Ich hatte erklärt, wie man den Atom Lite einrichtet und in der Arduino IDE programmiert und habe ein kleines Beispielprogramm zum austesten geschrieben.


Die eine Möglichkeit, den M5Stack Atom Lite mit Peripherie zu erweitern, nämlich über den unteren 9-Pin-Female-Header durch Draufstecken des Atom Lite auf ein Kit, hatte ich im Artikel Vorstellung des M5Stack Atomic TF-Card Moduls: SD-Kartenleser inkl. Atom Litebereits erläutert.

Die andere Möglichkeit ist es, über den 4-poligen I2C-Port Module zu verbinden. Das geschieht über ein 4-poliges, Grove-kompatibles Kabel, auf dessen beiden Ende ein weiblicher Stecker sitzt. So ein Kabel (in sehr kurz) wird mit der Unit mitgeliefert.

Eigentlich wollte ich die RFID-Reader-Unit, aber die war gerade ausverkauft und so habe ich mir zum Testen die ID-Unit für 5.50 € (Preis Stand Feb. 2022) mitbestellt. Das erschien mir bei der Bestellung angemessen.

Die ID-Unit wird in einer kleinen Plastik-Box geliefert, in die die Unit und das Mini-Kabel hineinpassen. Eigentlich ist die Box zu hoch für das Modul, passt aber trotzdem noch bequem in Hosen- oder Hemdtasche. Das Modul selbst ist nur 24 x 24 x 8.3 mm und damit ziemlich genauso groß wie der Atom Lite, lediglich ein bisschen flacher.



Auf der Vorderseite befindet sich nur I2C-Port und die Beschriftung "ID ATECC608B-TNGTLSU-G" und auf der Rückseite befindet sich nur die Pin-Belegung des I2C-Ports. Das Gehäuse hat zwei Löcher (wohl zum Einbauen mit Klemmbausteinen) und eine Schraube in der Mitte zum Öffnen des Gehäuses.

Die Spezifikation zur ID-Unit habe ich einmal ins Deutsche übersetzt:
UNIT ID ist ein Krypto-Coprozessor mit hardwarebasierter sicherer Schlüsselspeicherung, integriert in den ATECC608B-Hardware-Kryptografiechip, der die I2C-Kommunikationsschnittstelle verwendet. Der Chip verfügt über ein eingebautes 10 kb (wohl Kilobit, also 10240/8 = 1280 Bytes)-EEPROM zum Speichern von Schlüsseln, Zertifikaten, Daten, Verbrauchsaufzeichnungen und Sicherheitskonfigurationen. Die Konfiguration kann gegen Änderungen gesperrt werden, indem der Zugriff auf Speicherbereiche eingeschränkt wird.

Jeder ATECC608B wird mit einer garantiert eindeutigen 72-Bit-Seriennummer geliefert und enthält mehrere Sicherheitsfunktionen, um Angriffe auf das Gerät selbst oder logische Angriffe auf Daten zu verhindern, die zwischen Geräten übertragen werden.

Unterstützung der Trust&GO-Plattform (vorgefertigtes universelles Zertifikat für TLS-basierte Netzwerksicherheitsauthentifizierung, wie z. B.: AWS-IoT, Azure, Google und andere Cloud-Plattformen zur Überprüfung der Registrierung). Das interne Zertifikat des Verschlüsselungschips kann direkt über das Tool abgerufen werden um die automatische Registrierung ohne Offenlegung des privaten Schlüssels abzuschließen.


Schrauben wir doch das Gehäuse einmal auf und werfen wir einen Blick ins Innere.

Wir finden hier eine kleine Platine, an deren untere Seite der Grove-Port angelötet ist.

Oben hat es ein paar Kondensatoren und einen 7533L, einen 10-Bit-Digital-Analog-Wandler.

Rechts gibt es noch zwei 4.7 k&Ohm;-Widerstände und in der Mitte (unter U2) thront das Herzstück, der ATECC608B Krypto-Chip mit der Bezeichnung TW 043 688.

Mehr gibt es hier nicht zu sehen. Die Rückseite ist leer.

Der ATECC608B Krypto-Chip


Rechts sehen wir das Pinout des ATECC608B. Er kommt in Form eines SO8-Gehäuses für SMD-Bestückung daher.

Alles was an I2C reinkommt, geht also an den Krypto-Chip. Also schauen wir uns doch gleich mal dessen Data Sheet an.

Da fällt gleich der Vermerk rechts oben auf, übersetzt ins Deutsche:
Dies ist ein zusammenfassendes Dokument. Das vollständige Dokument ist erhältlich unter Abgabe einer Geheimhaltungsvereinbarung (NDA, Non Disclosure Agreement). Für weitere Informationen wenden Sie sich bitte an Ihren lokalen Microchip-Vertrieb.
Boah! Das müssen ja ultrageheime Sachen sein, die da nur gegen Geheimhaltungsvereinbarung verraten werden.

Für mich riecht so etwas ja immer etwas nach Security by obscurity, also "Sicherheit durch Verdunkelung". Warum muss man denn hier irgend etwas geheimhalten? Die ganzen Verschlüsselungs- und Hash-Algorithmen sind doch öffentlich bekannt. Gute Kryprografie zeichnet sich dadurch aus, dass sie auch noch sicher ist, wenn genau bekannt ist, wie sie funktioniert. Hier wird es doch wohl keine Sicherheitslücke im ATECC608B-Crypto-Chip geben, die nicht offen gelegt werden darf? Vielleicht eine Hintertür für die NSA? Wer weiß...

Aber schauen wir mal, was uns das Standard Data Sheet für Nichtgeheimnisträger so verrät...

Doch vorher nochmal wegen des Preises: Meine späteren Recherchen haben ergeben, dass es den ATECC608B-Crypto-Chip "nackt" (SO8-SMD) schon für ca. 85 Eurocents. z. B. von Mouser gibt. Und der Chip selbst kann schon I2C bei 2V bis 5.5V , könnte also direkt so an die Leitungen (Grove hat 5V) angeschlossen werden. Man zahlt für Platine, Stecker und Gehäuse also schon einen deftigen Aufschlag, jetzt relativ gesehen zu dem, was unbedingt nötig ist. Aber wenn man die Teile jetzt nicht gerade dutzend oder hundertfach braucht, kann man mit dem Preis wohl ganz gut leben. Insbesondere, wenn man nur ein bisschen damit herumexperimentieren will.

Dann schauen wir uns doch mal an, was der ATECC608B so leistet: Standard I2C ist schon mal gut, eine Spannungsspanne von 2 bis 5.5 Volt ist auch sehr gut. Damit kann er direkt an 3.3V-Mikrocontrollern (ESP8266, ESP32, STM32, Raspberry Pi) und an 5V-Mikrocontrollern (Arduino) betrieben werden.

Das direkt über I2C nach außen kommuniziert wird, ist auch gut. Denn dann laufen die sicherheitsrelevanten Dinge ausschließlich intern ab und können nicht an irgendwelche Leitungen abgehört werden. Ich gehe weiterhin davon aus, dass man bei Microchip Timing-Attacken kennt und da Sicherheitsmaßnahmen ergriffen hat und das der Chip nicht zu "öffnen" ist, um an die Daten zu kommen, ohne dass die Daten dabei zerstört werden.

Und was kann der ATECC608B jetzt so an Kryptografie?

Zu der AES-Verschlüsselung habe ich noch folgenden Absatz gefunden (ins Deutsche übersetzt):
Small Message Encryption

Enthält eine Hardware-AES-Engine zum Verschlüsseln und/oder Entschlüsseln kleiner Nachrichten oder Daten wie PII-Informationen. Unterstützt den AES-ECB-Modus direkt. Andere Modi können mit Hilfe eines Mikrocontroller-Hosts implementiert werden. Es gibt eine zusätzliche GFM-Berechnungsfunktion zur Unterstützung von AES-GCM.
Urgs. Dass der ECB (Electronic Code Book)-Modus beim Verschlüsseln eher unsicher ist und nciht eingesetzt werden sollte, sollte man wissen. Dann wird nämlich immer wieder der selbe Schlüssel pro Block angewandt. Wenn dann eine lange Folgen leerer Speicher kommt (Nullbytes) kann man an den Wiederholungen auf den Schlüssel zurückschließen.

Hier ein erläuterndes Beispiel von Kryptografie.de zum AES-Algorithmus:

Klartext:BeispielklartextBeispielklartext (32 Bytes, 2 Blöcke)
Schlüssel:ApfelstrudelKirschtorten (24 Zeichen, 192 bit, entsprechend wird diese Bitstärke gewählt)
Chiffrat CBC:E65C2C18 8C3204C5 D31532D4 338AAB92 2EAED13F 179CF793 CB34C673 DBE2E832 (hex)
Chiffrat ECB:E65C2C18 8C3204C5 D31532D4 338AAB92 E65C2C18 8C3204C5 D31532D4 338AAB92 (hex)*

*Beachten Sie die Wiederholung im Modus ECB

Wie man sieht, bekommt man im ECB-Modus zweimal den gleichen Code heraus für "Beispielklartext". Das ist unsicher und mit der richtigen Kryptoanalyse und genügend Datenmaterial bekommt man so den Schlüssel heraus. Es muss darum immer der CBC (Cipher Block Chaining) Modus benutzt werden. Denn dann hängt jeder chiffrierte Block auch vom vorhergehenden ab und nicht immer nur vom Schlüssel selbst. Im obigen Beispiel sieht man, dass sich der Code bei CBC nicht wiederholt.

ECB ist also unsicher. Der ATECC608B kann nur AES mit ECB. Um dem abzuhelfen, soll man den Mikrocontroller bemühen. Na toll, dann kann ich auch gleich den ESP32 zum Verschlüsseln in Software benutzen. Das ist bestimmt schneller.

Der Witz wäre ja gerade gewesen, dass alles intern im Krypto-Chip abläuft und da auch intern der Schlüssel, mit dem verschlüsselt wird, liegt. Schlüsselteile jetzt immer wieder in den Krypto-Chip hinein und aus ihm herauszutragen, um CBC zu realisieren, macht die Sache unsicher, kompliziert und wenig praktikabel.

Außerdem: was heißt "geeignet für kleiner Nachrichten"? Hört sich danach an, als ob das sehr langsam wäre. Warum sonst nur kleine Nachrichten? Aber ist der Sinn von AES in Hardware nicht eigentlich, dass das rasend schnell geschieht? Denn AES wurde auch im Hinblick darauf entwickelt, besonders performant in Hardware zu sein. Hier muss ich wohl mal später mal einen Performance-Test fahren...

Zu der asymmetrischen Verschlüsselung habe ich noch gefunden (übersetzt):
Elliptische Kurven

Der ATECC608B implementiert eine vollständige kryptografische Signaturlösung mit asymmetrischem (öffentlichem/privatem) Schlüssel auf Elliptic-Curve-Kryptografie und dem ECDSA-Signaturprotokoll. Das Gerät verfügt über Hardwarebeschleunigung für die NIST-Standard-P256-Prime-Kurve und unterstützt den gesamten Schlüssellebenszyklus von hochwertiger Generierung privater Schlüssel bis zur ECDSA-Signaturgenerierung, ECDH-Schlüsselvereinbarung und ECDSA-Public-Key-Signaturverifizierung.

Der Hardwarebeschleuniger kann solche asymmetrischen kryptografischen Operationen zehn- bis tausendmal schneller ausführen als Software, die auf Standard-Mikroprozessoren läuft, ohne das übliche hohe Risiko einer Schlüsselaufdeckung, die für Standard-Mikroprozessoren üblich ist.
Das hört sich doch eigentlich vielversprechend an. Einen Überblick über elliptische Kurven gibt Wikipedia.

Über den Zufallszahlengenerator gibt es auch noch Zusatz-Infos (übersetzt):
Zufallszahlen

Der ATECC608B kann mit seinem internen Zufallszahlengenerator qualitativ hochwertige Zufallszahlen erzeugen. Diese ausgeklügelte Funktion umfasst Runtime-Health-Tests, um sicherzustellen, dass die Werte, welche intern aus einer Rauschquelle generiert werden zum Zeitpunkt der Nutzung ausreichend Entropie enthalten. Der Zufallszahlengenerator ist darauf ausgelegt, die Anforderungen, die in den Dokumenten NIST 800-90A, 800-90B und 800-90C dokumentiert sind, zu erüllen. Die Zufallszahlen können für jeden Zweck verwendet werden, einschließlich als Teil der kryptografischen Protokolle des Geräts. Denn jede Zufallszahl ist im Wesentlichen einzigartig unter allen Zahlen, die jemals auf diesem oder einem anderen Gerät generiert wurden. Deren Einbeziehung in die Protokollberechnung sorgt dafür, dass Replay-Angriffe (d.h. das erneute Übertragen einer zuvor erfolgreiche Transaktion) fehlschlagen werden.
Auch das hört sich gut an. Gute Zufallszahlen kann man immer mal wieder zur Schlüsselgenerierung gebrauchen.

Und da endet dann auch das Summary Data Sheet. Keine Angabe über die I2C-Adresse, oder das Protokoll oder die Parameter, wie die Funktionen zu nutzen sind. Alles super streng geheim?

Data Sheet nur gegen Geheimhaltungsvereinbarung ist uncool

Aber auf der Produktseite von M5Stack zur Unit-ID finde ich noch folgenden Hinweis:
Note:
Before using this UNIT, it is recommended to read the ATECC508B datasheet , which only allows configuration prior to locking the chip. If you need to explore the full functionality, it is recommended to purchase multiple UNIT IDs for authentication.
Man muss also jeden ATECC608B* erst einmal konfigurieren und ihn dann sperren, bevor man ihn überhaupt benutzen kann. Hört sich kompliziert an. Und dann steht da noch, dass man sich am besten gleich mehrere UNIT IDs kauft, um mehrere Funktionen ausprobieren zu können.

Das ist ernüchternd. Zeitgleich muss das aus Sicherheitsgründen wohl sein. Allerdings erwähnt die Note den ATECC508B, den Vorgänger des ATECC608B und dafür habe ich noch ein vollständiges Data Sheet finden können, dass keiner vorherigen Geheimhaltungsvereinbarung bedarf. Die beiden Chips dürften halbwegs kompatibel sein. Dann nehme ich halt das als Grundlage zum Programmieren.

Außerdem habe ich die SparkFun ATECCX08A Arduino Library auf GitHub gefunden, die auch ein paar Examples enthält. Und zudem das Dokument "CryptoAuthentication Personalization Guide for ATSHA204A and ATECC508A" von Atmel. Atmel wurde ja damals von Microchip übernommen. Das hilft mir wohl bei der Erstkonfiguration.

Mal schauen ob ich damit einen Beispielcode hinbekommen, der mir auf Knopfdruck eine Zufallszahl auf der seriellen Schnittstelle ausgibt.

Personalisierung des ATECC508A/ATECC608B*

Auch in der Application Note "CryptoAuthentication Personalization Guide" findet sich gleich zu Anfang eine Warnung:
Vor der Verwendung von Atmel® CryptoAuthentication™ ATSHA204A und ATECC508A Geräte (Kryptogeräte), müssen zuvor einige Initialisierungsprozesse durchgeführt werden. Die Initialisierungsprozesse bestehen aus der Personalisierung des Geräts. Danach ist das Gerät zu sperren.
Im Personalisierungsschritt werden das Geräteverhalten, das Datenschlitzverhalten und die Daten selbst wird wie gewünscht konfiguriert. Nach dem der Personalisierungsprozess durchgeführt wurde, muss das Gerät gesperrt werden, um weitere Änderungen daran zu verhindern.
Außerdem finde ich den Absatz (übersetzt):
Nachdem das Kryptogerät konfiguriert wurde, besteht der nächste Schritt darin, die Konfigurationszone zu sperren. Vor dem Sperren der Konfiguration Zone ist weder Lesen noch Schreiben in den Data/OTP-Zonen erlaubt; daher muss die Konfigurationszone sein gesperrt, bevor Daten- und OTP-Zonen personalisiert werden.
Da muss ich mich wohl durch eine Reihe Data Sheets wühlen, wenn ich den Krypto Chip ernsthaft einsetzen will. Und bevor ich den Krypto-Chip ernsthaft einsetze. Denn die richtige Konfiguration sollte man sich da schon überlegen, denn sie ist unumkehrbar.

Zumindest die Konfiguration sollte ich aber trotzdem auslesen können und vielleicht gelingt es mir ja trotzdem, dem ATECC608B ein paar Zufallszahlen zu entlocken.

Den ATECC608B über I2C ansprechen

Stellt sich erst einmal die Frage, wie die ID Unit ansprechen. Über das I2C-Protokoll. Soviel ist schon mal klar. Aber über welchen Port?

Bei Microchip finde ich folgende Info (ins Deutsche übersetzt):
Die standardmäßige 7-Bit-I2C-Adresse ist 0x36. Die I2C-Adresse kann mit dem UpdateExtra-Befehl überschrieben werden.

Kein Anschluss unter dieser Nummer!

Nur, über 0x36 lässt sich die ID Unit nicht über Wire ansprechen.

Also mache ich mich auf die Suche, irgendwo muss sie sich ja verstecken...
for (int adr=0; adr<0x80; adr++) { Wire.beginTransmission(adr); int ret = Wire.endTransmission(); if (ret == 0) { Serial.printf("I2C-Gerät gefunden an Adresse 0x%02x\n", adr); id_adr=adr; } }
Nach einem kurzen Augenblick meldet sich die Routine zurück:
I2C-Gerät gefunden an Adresse 0x35
Okay. Mein ATECC608B hört also auf 0x35, nicht wie üblich* auf 0x36. Seltsam. Aber wenn das so ist.

Also erstmal irgendwas hingeschickt, um den ATECC608B aufzuwecken. Der antwortet gleich mit 4 Bytes, die folgenden Aufbau haben: Das antwortet er dann auch immer, es kommen immer die selben 4 Bytes zurück. Also durch die 508er Datasheets gewühlt, die man auch als vollständige Version im Internet findet. Und erfahren, dass man auch alle Messages an den ATECC "einpacken" muss, mit Länge und CRC und so.

Danach ist der ATECC608B bereit, erste Kommandos über I2C auszuführen. Und so habe ich geschafft, mir ein Script zu schreiben und mir ein paar Daten vom Chip zurückgeben zu lassen, die ich dann auf dem seriellen Monitor ausgegeben habe:
Suche ID-Unit... I2C-Gerät gefunden an Adresse 0x35 ID-Unit unter Adresse 0x35 gefunden. Teste ID-Unit ... ... Frage Versions-Info ab ... 07 00 00 60 03 83 bb ... Erzeuge ein paar Zufallszahlen zu je 32 Bytes ... 23 40 72 8e ec df 8e 03 59 86 66 75 75 63 7c bf 0f e2 be e5 88 c9 4c 84 18 66 29 0f c4 89 ff 7d 3a 75 20 23 9e f9 e1 16 a5 97 ed f9 09 ce 8a ae a7 d6 48 1f 1b bd b0 6c 0e ed 9b 36 f4 5e 09 87 34 4e 39 de 79 54 23 ce 4f 51 c7 f5 29 d8 8d fe 2b 1b ff 97 7e db 78 e9 46 71 66 d0 e2 c2 06 be 3c d1 83 27 fc c0 b2 c2 7d 23 85 c4 04 10 e4 f7 c0 1e aa 75 27 e1 f2 7e 2d 51 0d ab 04 e8 6a 67 2a 83 d9 ee d9 7b 69 c6 d2 48 03 fe 23 6a f7 68 98 b1 73 26 d7 dc e9 20 6b 5f c3 63 b7 8d 77 08 0c 67 b4 0a ab 2c 7d af 9d fb eb ef 77 76 84 23 be b0 c3 70 e1 45 f5 80 b4 20 af 2b ae 93 b9 aa ba a5 54 8d 89 56 6e c4 5c 83 c3 7d 3f 70 b5 8a 9b bb 23 b4 6e 9c 4a d8 66 b4 e5 4f 1a 41 1c d6 2b db 7e 82 13 ae 8b 26 2e c8 49 b3 5d f6 1e 56 bf eb 41 5e 10 23 bd bc a0 ea 67 a4 13 18 6b da ac 8a 22 10 d8 4b dd 83 37 f5 91 5d 13 9f e7 7a 9a 34 47 aa a4 b8 40 29 23 0c d4 66 06 d7 9f e3 c2 22 ca c3 84 ba 8d d7 1d 84 c7 21 ef 61 f7 ac da cb f5 92 eb ad cb 3b b4 33 39 23 ce 88 31 5a 9c 19 ce 92 43 d5 cb df fb f4 77 42 ca 42 21 7b 59 9d 89 59 d5 db b7 b5 5c a8 63 c8 f9 00 ... Lese Konfigurations-Zone (128 Bytes) und werte sie aus (Alle Werte hex) ... 23 *** 128 Bytes Speicherauszug *** CRC16 Revision Number: 00 00 60 03 Serial Number: *** 9 Bytes lange Seriennummer *** I2C Address: 35 OTP Mode: 00 (0xaa: Read Only Mode; 0x55: Consumption Mode) Counter 0: ff ff ff ff 00 00 00 00 Counter 1: ff ff ff ff 00 00 00 00 User ExtraBytes: 00 00 Lock Value: 00 (locked) Lock Config: 00 (locked) ...
Die Versionsnummer "00 00 60" passt schonmal zum ATECC608B. Gut.

Danach versuche ich dem Gerät ein paar Zufallszahlen zu entlocken. Funktioniert auch. Komisch, ich dachte für weitere Funktionen muss das Gerät gesperrt sein. Naja, vielleicht ja auch nur für die Funktionen, die Schlüssel benutzen.

Die Zufallszahlen sind auf jeden Fall schnell berechnet und wenn das Versprochene von oben stimmt, dann dürften die auch aus krytografischer Sicht her taugen. Hätte ich schon mal eine vermeintlich taugliche Zufallszahlenquelle. Natürlich werde ich vorher noch Verteilung und Entropie austesten, bevor ich beginne, ihr zu vertrauen.

Danach lese ich die Konfiguration aus. Die Seriennummer sieht zufällig aus. Ich glaube jetzt einfach mal, dass sie einmalig ist. Die I2C-Adresse wird noch einmal mit 0x35 bestätigt. Beim OTP Mode steht etwas komisches drin. Da sollte eigentlich nicht "00" drinstehen.

Aber der Schock kommt dann bei "Lock Value: 00 (locked)". Das heißt, das Gerät ist bereits personalisiert und gesperrt worden. Ich war das ganz sicher nicht. Denn zum sperren muss man einen speziellen Befehl absetzen, den ich garantiert noch nicht abgesetzt habe. Auch nicht aus Versehen, das schließe ich aus, denn Nachrichten an den ATECC608B werden von ihm nur mit gültiger CRC angenommen und ausgeführt.

Ohje, was haben die mir da geschickt?

Da habe ich also eine bereits gebrauchte ID Unit bekommen.* Die hatte schon einmal jemand anders und hat sie auch schon personalisiert und gesperrt.* Und dann wieder zurück geschickt.* Oder schon die Chinesen haben Rückläufer eingelötet?* (Auflösung dazu im Nachtrag vom 2022-03-03)

Das macht das Teil für mich natürlich wertlos. Zum einen kann ich es nicht mehr konfigurieren, zum anderen kann ich dem Teil natürlich nicht vertrauen. Und die vielleicht bereits im ATECC608B hinterlegten Schlüssel weiter zu benutzen, wäre ziemlich dumm. Denn sicher hat irgendwer irgendwo eine Kopie der Schlüssel und wartet vielleicht nur darauf, dass ich die auf diesem ATECC608B benutze.

Ist mit 5.50 € jetzt kein großer Verlust. Zum Testen, das die Units über I2C funktionieren, hat es gereicht und als Zufallszahlengenerator wird er auch noch taugen. Aber vielleicht bekomme ich ja auch Ersatz vom Händler. Ein gebrauchter, durch die Sperre unbrauchbar* gemachter Krypto Chip dürfte wohl nicht ganz der bestellten Ware entsprechen.

Fazit

Unit-Module über I2C an den Atom Lite anzuschließen ist eigentlich kinderleicht. Für die meisten gibt es wohl auch funktionierende Beispiele und alles ist ganz easy.

Die ID Unit mit ATECC608B Krypto-Chip allerdings ist mehrfach kompliziert: Dass ich dann noch einen gesperrten, schon gebrauchten* ATECC608B bekommen habe, setzt dem Ganzen dann natürlich die Krone auf.

Keine Empfehlung von mir deshalb für den Hobby-Bereich. Das Teil hat eine extrem steile Lernkurve und wird euch höchstwahrscheinlich nur frusten.

Nachtrag 2022-02-28

Nachdem ich das mit dem bereits gesperrten ATECC608B an meinen Händler herangetragen habe, war dieser so freundlich, noch am selben Tag Ersatz an mich herauszuschicken. Sobald die neue ID Unit da ist, werde ich sie natürlich gleich testen, ob sie diesmal auch neu und ungesperrt ist. Ich werde dann an dieser Stelle wieder berichten.

Auch habe ich mich an M5Stack direkt gewandt, um zu sehen, was die als Hersteller der Units dazu zu sagen haben.

*: Nachtrag 2022-03-03

M5Stack hat mir geantwortet und gesagt, dass der Chip schon gesperrt verkauft wird. Und mir außerdem einen Link auf die Produktseite des ATECC608B-TNGTLS bei Microchip genannt. ATECC608B-TNGTLS ist die genaue Produktversion des Chips, der in der Unit ID eingebaut ist.

Dort heißt es (ins Deutsche übersetzt):
Der Microchip ATECC608B-TNGTLS ist das sichere Trust & GO-Element der Trust-Plattform für die CryptoAuthentication-Familie. Das Gerät wird vorkonfiguriert und mit Standard-Fingerabdruckzertifikaten und -schlüsseln bereitgestellt. Die Konfiguration und Anmeldeinformationen sind im Gerät gesperrt und können nicht geändert werden.
Auf der Produktseite von M5Stack zur Unit-ID heißt es aber auch heute noch (übersetzt):
Vor der Verwendung dieser Unit wird empfohlen, das ATECC508B-Datenblatt zu lesen, das nur eine Konfiguration vor dem Sperren/Verriegeln des Chips zulässt. Wenn Sie die volle Funktionalität erkunden möchten, wird empfohlen, mehrere UNIT IDs zu erwerben.
Verlinkt ist das Datenblatt des Vorgängers ATECC508B. Dieser Umstand, der Hinweis und auch der Umstand, dass ein Beispiel für den ATECC508B (Arduino/Github) verlinkt ist, ohne explizit zu erwähnen, dass das alles für den Vorgänger ist, verleitet natürlich dazu, anzunehmen, dass der ATECC608B-TNGTLS mit dem ATECC508B kompatibel ist.

Dem ist aber in Wahrheit nicht so. Der ATECC608B ist nur teilweise abwärts kompatibel zum ATECC508B. Aber nur das Datenblatt zum 5er ist frei zugänglich, für das zum 6er muss eine Geheimhaltungsvereinbarung abgeschlossen werden. Darum gibt es auch keine richtig funktionierende Bibliothek zum 6er, weil eben: geheim. Und in Ermangelung von aktuellen Informationen hat man sich bei M5Stack wohl einfach auf den 5er bezogen, was natürlich in die Irre führt. Ich persönlich finde das einen eher schlechten Stil. Ich meine, da hätte man drauf hinweisen müssen, dass weder verlinktes Data Sheet noch verlinktes Beispiel zum verkauften Produkt passen.

Kompatibel und brauchbar ist der 6er vielleicht noch bezüglich des Zufallszahlengenerators. Eine Konfiguration und Sperrung, wie im Data Sheet des 5ers erwähnt entfällt allerdings. Der 6er kommt ja schon vorkonfiguriert und gesperrt. Vielleicht kann man auch deshalb gleich den Zufallszahlengenerator benutzen, weil die Sperre eben schon gesetzt ist. Wie man auf den Zufallszahlengenerator zugreift, kann man aus dem 5er Data Sheet und der Sparkfun-Library schließen. Für den Rest braucht man das 6er Data Sheet, was es eben nur gegen NDA gibt.

Auf eine Bibliothek für den 6er wird man wohl vergeblich hoffen, denn das zu programmieren und zu veröffentlichen würde ja dann die Geheimhaltungsvereinbarung verletzen und Ärger mit Microchip bedeuten.

Das war eine ganz schöne Odyssee, das herauszufinden. So gut wie überall im Internet wird nur auf den 5er Bezug genommen, eben weil der 6er einem NDA unterliegt. Und da kann ich nur erneut meine Meinung wiederholen: Data Sheet nur gegen Geheimhaltungsvereinbarung ist uncool! Das verhindert natürlich, dass Leute freie Bibliotheken erstellen können und zum Schluss schneidet sich damit Microchip ins eigene Fleisch. Außer, dass es unsympatisch macht, setzt man natürlich weniger ab: Hobbyisten kann man so ein Teil nur schwer verkaufen.

Nachtrag 2022-04-02

Mittlerweile wurde auch die Produktseite der ID Unit bei M5Stack korrigiert. Dort ist nun zu lesen:
Note:

This pre-provisioned Trust&GO secure element supports 'Microchip Trust Platform' only. For more details, please refer to below link. https://www.microchip.com/en-us/product/ATECC608B-TNGTLS
Man hat meine e-mail bei Hersteller in China also ernst genommen und mit dem jetzigen Text sollte es keine große Verwirrung bei den Käufern durch die Nennung des falschen Datenblattes mehr geben. Ich habe auch meinem deutscher Händler nochmals per e-mail Bescheid gegeben und eine Korrektur ihrer Produktseite vorgeschlagen, es hat sich allerdings noch nichts geändert.