Ich setze mich gerade intensiv mit dem Ding auseinander.
Der Chip heißt "ATECC508A" und ist über /dev/i2c-1 erreichbar.
Diverse Dokumentation gibt es hier:
https://www.microchip.com/wwwproducts/en/ATECC508A
Das abgespeckte DataSheet gibt es hier:
http://ww1.microchip.com/downloads/en/D ... 05928A.pdf
Ein (inzwischen veraltetes) DataSheet habe ich per NDA bekommen. Das aktuelle findet man per Google, lässt sich direkt beim Hersteller runterladen.
Software unter anderem:
-
https://git.kernel.org/pub/scm/linux/ke ... tmel-ecc.c
-
https://github.com/MicrochipTech/cryptoauthlib
-
https://github.com/RevolutionPi/cryptoa ... ssl-engine
- strace piSerial -s
Der Chip unterstützt ausschließlich ECC mit P-256 sowie SHA-256 und MAC. Und sehr viele kleine Extra-Features und -Optionen die mich gerade wahnsinnig machen.
Das größte Problem das ich derzeit habe: Man muss den Chip konfigurieren. Das ist kompliziert. Dann muss man die Konfiguration locken und danach sind keine Änderungen mehr möglich.
Ein Fehler und der Chip ist Schrott. Dann müsste ich mir erstmal einen neuen besorgen und einen Kollegen mit ruhigen Händen bitten, den Lötkolben zu schwingen.
Wenn Kunbus den Chip selbst nutzen will für mehr als nur die Seriennummer auszulesen, muss Kunbus die Konfiguration auch definieren, die lässt sich dann nicht mehr ändern.
Das könnte man, soweit ich einschätzen kann, aber so gestalten, dass Kunbus einen Teil der 16 Key Slots selbst nutzt und die anderen so konfiguriert, dass die User (also wir) diese nutzen können.
Was mir persönlich gerade sehr weiterhelfen würde sind vollständige Beispielkonfigurationen. Und ich habe die Vermutung, dass Kunbus an demselben Punkt steht
> Für uns wäre interessant ob und inwieweit wir den eingebauten Crypto-Chip nutzen können um die Zertifikate und sonstige Secrets so ablegen zu können, dass sie nicht von dem RevPi gestohlen oder kompromittiert werden können (mit vertretbarem Aufwand
). Gibt es dafür Best Practices?
Private Keys kann man ablegen. Entweder selbst generieren und in den Chip hochladen, oder vom Chip generieren lassen. Laut Doku lässt sich der Private Key nicht mehr runterladen. Der Chip kann dann ECDSA und ECDH berechnen. Das dürfte für TLS ausreichen.
Zertifikate ist schwieriger, die können ja beliebig groß werden. Da ist scheinbar vorgesehen, dass man bestimmte Anteile vom Zertifikat in einem bestimmten Format in den Chip lädt. Das komplette Zertifikat müsste dann auf dem RevPi wieder zusammengesetzt werden. So ganz habe ich das Konzept noch nicht durchdrungen. Alternativ kann man das Zertifikat einfach ins Dateisystem oder auf einen Webserver im Internet legen. Zertifikate enthalten keine vertraulichen Informationen, bei jedem TLS-Verbindungsaufbau schiebt man das Zertifikat eh offen durch die Leitung.
