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Ω-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:

1 MHz Standard I2C Interface
1.8V to 5.5V IO Levels, 2.0V to 5.5V Supply Voltage; <150 nA Sleep Current; Operating Current Typical 2 mA

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?

Protected storage for up to 16 keys, certificates or data:. Hört sich jetzt gut an. Aber 10 Kilobit / 1280 Bytes EEPROM-Speicher ist jetzt nicht so viel. Ein RSA-Key hat normalerweise schon 4096 bits, also 512 Bytes. Passen gerade mal zwei in den Speicher (Spoiler: der ATECC680B kann kein RSA, nur ECC, das hat kürzere Schlüssel). Nehmen wir die 1280 Bytes durch 128 bit (16 Bytes), die der Chip in AES verschlüsseln können will, dann haben wir Platz für 80 Schlüssel. Bei SHA-256 (32 Bytes) bleibt nur noch Platz für 40 Hashes. Bei SHA-512 (64 Bytes) wäre noch Platz für 20 Schlüssel. Zertifikate sind natürlich wesentlich länger. Das hört sich viel an, ist aber eigentlich doch eher knapp. Man kann aber damit leben.
Elliptic Curve: ECDSA: FIPS186-3 Signature, ECDH: FIPS SP800-56A Diffie-Hellman Schlüsselaustausch, NIST Standard P256 (ECC secp256r1) Support: Schade, kein RSA; "nur" elliptische Kurven. Okay, war ja fast klar. RSA-Verschlüsselung braucht schon ordentlich Rechenpower. Das will man so einem kleinen Chip nicht abverlangen.
SHA-256 & HMAC Hash including off-chip context save/restore: SHA2 mit 256 Bit als Hash-Algorithmus ist zwar nicht schlecht, aber in meinen Augen derzeit Untergrenze für kryptologische Sicherheit. SHA Version 3 mit 512 Bit wäre natürlich sicherer, besonders im Hinblick auf kommende Quantencomputer. Ist derzeit aber noch ausreichend. Mit der HMAC Funktion kann ein Hash unter Zuhilfenahme eines intern im Krypto-Chip gespeicherten Schlüssels errechnet werden.
AES-128: Encrypt/Decrypt, Galois Field Multiply for GCM: Das selbe, was ich eben zu SHA-256 schrieb, gilt auch hier. AES mit 128 bit Schlüssellänge zum Verschlüsseln ist derzeit noch ausreichend, aber im Hinblick auf kommende Quantencomputer in ein paar Jahren oder Jahrzehnten eventuell zu schwach. Ansonsten ist AES als Algorithmus wohl derzeit eine sehr gute Wahl.
Networking Key Management Support: Turnkey PRF/HKDF calculation for TLS 1.2 & 1.3, Ephemeral key generation: das werde ich wohl nicht nutzen
Secure Boot Support: Das ist mehr was, um PCs vor Boot-Viren zu schützen und auch sonst sicherer zu machen. Das überlassen wir mal den PC-Mainboard-Herstellern.
Internal High-Quality NIST SP 800-90A/B/C Random Number Generator (RNG): Gute Zufallszahlen sind gar nicht so einfach zu generieren. Hier müsste man mal schauen, was die NIST für einen Standard aufgestellt hat. Sicher kann ich das mal gebrauchen, wenn die Zufallszahlen taugen.
Two High-Endurance Monotonic Counters: Damit werden ich einen Zähler hochzählen können, der sich von außen nicht mehr zurücksetzen lässt. Das dürfte interessant für Anwendungen sein, in denen man etwas zählen will, für das bezahlt werden muss. Etwa, wenn man etwas nur 100 mal benutzen darf, bevor es den Dienst verweigert und dann erst wieder freigeschaltet werden muss.
Unique 72-Bit Serial Number: Diese ID-Nummer könnte man benutzen, um sich irgendwo auszuweisen. Sie soll garantiert weltweit einmalig sein. Natürlich muss man dann auch jedesmal prüfen, ob der Krypto-Chip auch echt ist. Sonst erledigt es ein kleiner Mikrocontroller, der auf I2C reagiert, dass auf die I2C-Anfrage nach der ID jede beliebige ID zurückgegeben wird.
Standard Industrial Temperature Range: -40°C to +85°C: Schön zu wissen, dass das Ding nicht gleich über den Jordan ist, wenn man es in der Winter-Kälte oder in der Sommer-Hitze im Auto vergisst.

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 erfü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:

1 Byte: Länge der Nachricht (all inklusive)
n Bytes: Nachricht
2 Bytes: 16 Bit-CRC über die Nachricht

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:

Es gibt kein Beispiel-Programm. Nur einen Verweis auf eine alte Arduino-Library für den Vorgänger ATECC508A und das ist für den Arduino und nicht für den ESP32, die Programmbibliothek müsste man erst einmal anpassen
Es gibt kein aktuelles, vollständiges Data Sheet. Sondern erst nach Geheimhaltungsvereinbarung. Na danke.
Den Chip anzusprechen ist etwas kompliziert und ohne Data Sheet hat man da sowieso verloren.
Über die Funktionen des Chips benutzen zu können, braucht es schon ein gerüttelt Maß kryptografisches Hintergrundwissen. Mit dem Chip eine wirklich sichere Anwendung zu entwickeln und dabei keine Fehler zu machen, ist sehr schwierig, dafür muss man Experte sein. Die Stolperfalle mit dem nur ECB und für CBC nehme man doch bitte noch einen Mikrocontroller zur Unterstützung her, ist so ein Beispiel, was man aus Unwissenheit schnell falsch machen kann.

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.