Verschlüsselung auf dem PIC32: AES und SHA Implementierung

Verschlüsselung auf dem PIC32 ist längst kein „Nice-to-have“ mehr, sondern in vielen Projekten eine Grundvoraussetzung: Firmware-Updates sollen manipulationssicher sein, Sensordaten dürfen nicht im Klartext übertragen werden, und Zugangsdaten müssen geschützt gespeichert bleiben. In der Praxis stellt sich dabei oft die Frage, wie man robuste Kryptografie auf einem Mikrocontroller sauber umsetzt – ohne unnötig viel Rechenzeit, RAM oder Flash zu verbrennen. Genau hier kommen etablierte Verfahren wie AES (symmetrische Verschlüsselung) und SHA (Hashing) ins Spiel. Dieser Artikel zeigt, wie eine Verschlüsselung auf dem PIC32 mit AES und SHA sinnvoll geplant und umgesetzt wird: von der Algorithmuswahl über Betriebsmodi und Schlüsselmanagement bis zur konkreten Integration in Toolchains wie MPLAB X und Frameworks wie MPLAB Harmony. Gleichzeitig lernen Sie typische Stolperfallen kennen, damit die Lösung nicht nur „funktioniert“, sondern auch sicher und wartbar bleibt.

Warum AES und SHA auf dem PIC32 zusammengehören

AES und SHA erfüllen unterschiedliche Aufgaben, werden in Embedded-Systemen aber häufig kombiniert. AES (Advanced Encryption Standard) verschlüsselt Daten mit einem geheimen Schlüssel, sodass ein Angreifer ohne Schlüssel keinen sinnvollen Inhalt erhält. SHA (Secure Hash Algorithm) dagegen erzeugt einen Prüfsummenwert (Hash), der Änderungen an Daten zuverlässig sichtbar macht. In vielen Sicherheitsprotokollen steckt beides: Daten werden verschlüsselt (Vertraulichkeit) und zusätzlich authentifiziert bzw. signiert (Integrität/Authentizität). Ohne Authentizität ist reine Verschlüsselung oft unzureichend, weil ein Angreifer verschlüsselte Daten manipulieren kann, ohne sie lesen zu müssen.

Ein typisches Muster im PIC32-Umfeld ist daher:

• AES-CTR oder AES-CBC für die Verschlüsselung von Nutzdaten
• SHA-256 als Hashbasis für Integritätsprüfungen, z. B. in HMAC
• AES-GCM oder AEAD (Authenticated Encryption with Associated Data), wenn Vertraulichkeit und Integrität in einem Schritt benötigt werden

Gerade in Netzwerkprojekten (TLS, MQTT, HTTPS) kommen Sie praktisch nicht an SHA-256 und AES vorbei. MPLAB Harmony stellt hierfür eine eigene Krypto-Bibliothek bereit, inklusive Beispielen und Konfigurationen, die auf Microchip-32-Bit-Targets ausgerichtet sind (siehe MPLAB Harmony Crypto Library sowie das Repository Harmony 3 Cryptographic Library auf GitHub).

Software vs. Hardware-Krypto: Was kann Ihr PIC32 wirklich?

Ob Sie AES und SHA rein in Software oder mit Hardware-Unterstützung ausführen, hängt vom konkreten PIC32-Derivat ab. Einige Familien (z. B. bestimmte PIC32MZ/PIC32MK-Varianten) bieten Hardware-Crypto-Engines, die AES und Hashfunktionen beschleunigen können. Der Vorteil: deutlich mehr Durchsatz, geringere CPU-Last und oft ein besseres Energieprofil. Der Nachteil: höhere Komplexität bei der Konfiguration und strengere Anforderungen an Datenpuffer (Ausrichtung, Blockgrößen, DMA-Handling).

Microchip selbst verweist darauf, dass in Harmony oft sowohl Software- als auch Hardware-Konfigurationen existieren und per Option umgeschaltet werden können (Beispielhinweise und typische Projektpfade finden sich in der Knowledge-Base How to use the hardware Crypto function on PIC32MZ or PIC32MK). Für den Einstieg lohnt sich, mit einer funktionierenden Software-Variante zu beginnen und anschließend auf Hardware zu migrieren – so trennen Sie „Kryptologie-Logik“ von „Treiber-/Beschleuniger-Details“.

Entscheidungshilfe: Wann lohnt Hardware-Beschleunigung?

• Hoher Datendurchsatz: z. B. Ethernet/TLS, große Datenlogger, verschlüsselte Massenspeicher
• Striktes Energie-Budget: CPU-Zeit ist Energie; Hardware kann hier Vorteile bringen
• Echtzeit-Anforderungen: deterministischere Laufzeiten als bei CPU-Lastspitzen
• Einfaches Projekt (wenig Daten): häufig reicht Software, wenn Ressourcen nicht kritisch sind

AES auf dem PIC32: Betriebsmodi, IVs und typische Embedded-Anforderungen

AES arbeitet blockweise mit 128-Bit-Blöcken (16 Byte). Entscheidend für die praktische Sicherheit ist nicht nur „AES-128/192/256“, sondern vor allem der Betriebsmodus (Mode of Operation). In Embedded-Projekten sind folgende Modi besonders relevant:

• CBC (Cipher Block Chaining): weit verbreitet, benötigt Padding und ein zufälliges IV; Integrität muss separat abgesichert werden.
• CTR (Counter Mode): streamartig, kein Padding nötig; benötigt einen eindeutigen Nonce/Counter pro Schlüssel; Integrität ebenfalls separat.
• GCM (Galois/Counter Mode): kombiniert Verschlüsselung und Authentifizierung (AEAD), ideal für sichere Protokolle, aber etwas komplexer.

IV/Nonce: Das häufigste Sicherheitsproblem

Ein IV (Initialisierungsvektor) oder Nonce ist kein „optional nettes Extra“, sondern Sicherheitsgrundlage. Bei CBC muss das IV für jede Nachricht frisch und unvorhersehbar sein. Bei CTR/GCM muss die Nonce pro Schlüssel eindeutig sein; Wiederverwendung führt zu katastrophalen Lecks. Für PIC32-Projekte bedeutet das: Sie benötigen eine zuverlässige Quelle für Zufall/Entropie oder ein robustes Nonce-Konzept (z. B. monotoner Zähler in nichtflüchtigem Speicher plus Geräte-ID). Die MPLAB Harmony Crypto Library bietet neben AES und Hashfunktionen auch RNG-Funktionen und Beispiele, die als Ausgangspunkt dienen können (Cryptographic Library).

Durchsatz grob abschätzen: Blockgröße und Zeit

Gerade bei Netzwerk- oder Logging-Anwendungen ist es sinnvoll, den AES-Durchsatz überschlägig zu rechnen. Eine einfache Faustformel ist:

$\mathrm{Durchsatz}=\frac{B\times 16}{t}$

Dabei ist B die Anzahl der verschlüsselten AES-Blöcke (je 16 Byte) und t die benötigte Zeit in Sekunden. Wenn Sie z. B. 4096 Byte verschlüsseln, sind das 256 Blöcke. Messen Sie die Zeit (z. B. per Timer) und setzen Sie die Werte ein. Für eine realistische Bewertung sollten Sie neben der reinen AES-Funktion auch Kopieraufwand, Pufferverwaltung und ggf. DMA-Setup berücksichtigen.

SHA auf dem PIC32: Hashing, Integrität und HMAC in der Praxis

SHA-Funktionen erzeugen aus beliebigen Daten einen festen Hashwert. Für neue Designs ist SHA-256 der Standard. SHA-1 gilt als kryptografisch überholt und sollte für Sicherheitszwecke vermieden werden. In Embedded-Systemen wird SHA häufig für folgende Aufgaben eingesetzt:

• Firmware-Integritätscheck: Hash über Firmware-Image, Vergleich mit bekanntem Referenzwert
• Message Authentication: HMAC(SHA-256) zur Manipulationssicherheit von Nachrichten
• Schlüsselableitung: z. B. HKDF (auf SHA-256-Basis), insbesondere in Protokollen

MPLAB Harmony bietet für Hashalgorithmen eigene Beispiele und Demonstrationsprojekte, die die Anwendung auf Microchip-Plattformen zeigen (u. a. Hash- und Large-Hash-Demos: Large Hash Crypto Applications). Solche Beispiele sind wertvoll, weil sie nicht nur den Algorithmus aufrufen, sondern auch Messung, Puffergrößen und Konsolenausgabe für Vergleichswerte enthalten.

Warum HMAC oft wichtiger ist als „nur SHA“

Ein reiner Hash beweist lediglich, dass Daten sich nicht geändert haben – aber nicht wer sie erzeugt hat. Sobald ein Angreifer den Hash mit berechnen kann, kann er manipulierte Daten samt neuem Hash senden. HMAC löst dieses Problem, indem ein geheimer Schlüssel in die Hashbildung einfließt. Für Embedded-Kommunikation (z. B. Sensor->Gateway) ist HMAC(SHA-256) daher häufig die praktikabelste Integritätsabsicherung, wenn keine asymmetrischen Signaturen benötigt werden.

Toolchain und Framework: So integrieren Sie AES und SHA sauber

Auf PIC32-Projekten wird Kryptografie selten „nackt“ implementiert, sondern über Bibliotheken, die bereits für die Plattform optimiert sind. Zwei gängige Wege sind:

• MPLAB Harmony Crypto Library für integrierte Krypto-Funktionen im Microchip-Ökosystem (Dokumentation: Harmony Crypto Library, Quellcode: Microchip-MPLAB-Harmony/crypto)
• wolfSSL/wolfCrypt für TLS/Netzwerkprojekte und standardnahe Krypto-Primitives, teils integriert in Harmony-Netzwerkdemos (Beispiel: TCP/IP wolfSSL TCP Client)

Praktisches Vorgehen in MPLAB X mit Harmony

• Projektbasis wählen: Starten Sie mit einem offiziellen Crypto-Beispiel (z. B. Encrypt/Decrypt-Demo), um Build-System, Include-Pfade und Konfiguration „richtig“ zu haben (Überblick: Encrypt/Decrypt Crypto Demonstration).
• Software zuerst: Lassen Sie AES/SHA zunächst softwarebasiert laufen. Damit isolieren Sie Logikfehler (Padding, IV, Keylength) von Hardwaretreiber-Themen.
• Hardware-Option aktivieren: Wenn Ihr PIC32 eine Crypto-Engine besitzt, schalten Sie danach in der Konfiguration auf Hardware um (Hinweise dazu: Microchip Support-Artikel zur Hardware-Crypto-Nutzung).
• Messung einbauen: Nutzen Sie Timer (z. B. Core Timer) und messen Sie AES- und SHA-Laufzeiten mit realistischen Payloads.

Schlüsselmanagement: Der „unsichtbare“ Teil, der über Sicherheit entscheidet

Der stärkste AES-Algorithmus bringt wenig, wenn der Schlüssel unsicher gespeichert ist. In vielen Embedded-Projekten liegt der Schlüssel schlicht im Flash – leicht extrahierbar durch Debug-Interfaces, Fehlkonfigurationen oder physische Angriffe. Besser ist es, Schlüssel entweder aus einem Geheimnis abzuleiten, das nicht auslesbar ist, oder sie in einem dedizierten Secure Element zu speichern.

Microchip bietet hierfür die CryptoAuthentication-Familie, die sichere Schlüsselspeicherung und hardwarebasierte Kryptofunktionen bereitstellt (Überblick: CryptoAuthentication Secure Key Storage). Ein bekanntes Beispiel ist der ATECC608A, der unter anderem AES-128 und SHA-256 in Hardware unterstützt und Schlüssel geschützt halten kann (siehe Datenblatt: ATECC608A Device Summary Data Sheet).

Praxisnahe Optionen für PIC32-Projekte

• Secure Element: Schlüssel verlassen das Secure Element nie; PIC32 nutzt nur die Ergebnisse (z. B. Signaturprüfung, HMAC).
• Schlüsselableitung: Ableitung aus Geräte-spezifischen Geheimnissen (nur sinnvoll, wenn diese wirklich geschützt sind).
• Trennung von Schlüsseln: Verschiedene Schlüssel für Verschlüsselung, HMAC, Updates, Debug – statt „einem Master-Key für alles“.
• Debug-Schnittstellen absichern: Konfigurationen und Produktionsabläufe so gestalten, dass Debug nicht unkontrolliert offen bleibt.

Tests und Verifikation: So vermeiden Sie „kryptografisch korrekt, aber falsch implementiert“

Krypto-Implementationen scheitern in Embedded-Projekten häufig an Details: Endianness, Padding, IV-Handhabung, Buffer-Offsets, falsch verstandene API-Verträge oder Timing-Probleme bei Streaming-Hashes. Deshalb ist ein systematischer Testansatz Pflicht. Bewährt haben sich:

• Known Answer Tests (KAT): feste Eingaben mit bekannten Ausgaben, ideal für AES und SHA
• Vergleich gegen Referenz: Hash/Encrypt auf dem PC mit OpenSSL oder einer bekannten Library und Vergleich der Ergebnisse
• Monte-Carlo-Tests: wiederholte Verschlüsselungen/Hashläufe zur Robustheitsprüfung

Für offizielle und verbreitete Testvektoren ist NIST eine zentrale Anlaufstelle. Der Bereich CAVP (Cryptographic Algorithm Validation Program) bietet Informationen, Spezifikationen und Testmaterialien zu AES und Hashalgorithmen, die Sie für eine informelle Verifikation nutzen können (Übersicht: NIST CAVP, AES-Blockchiffren: NIST Block Ciphers, Secure Hashing: NIST Secure Hashing).

Performance und Speicher: Typische Engpässe und wie Sie sie umgehen

PIC32-Systeme haben im Vergleich zu 8-Bit-Controllern viel Leistung, aber Kryptografie kann dennoch zur Bremse werden – insbesondere bei TLS, großen Datenmengen oder wenn mehrere Sicherheitsfunktionen parallel laufen (z. B. Verschlüsselung + Logging + Sensorfusion). Typische Engpässe sind:

• RAM-Puffer: AES-CBC braucht Blockausrichtung und ggf. Padding-Puffer; SHA kann Streaming-Puffer erfordern.
• Kopieroperationen: Daten mehrfach zu kopieren kostet Zeit; besser sind „in-place“-Operationen, wo sicher möglich.
• Interrupt-Latenzen: Lange Krypto-Routinen können zeitkritische ISR stören; hier helfen kurze Blöcke oder Hardware-Offload.
• IO statt CPU: Oft ist nicht AES selbst langsam, sondern das Einlesen/Schreiben (SPI, SD, Ethernet). Messen Sie Ende-zu-Ende.

Wenn Harmony-Beispiele nutzen, profitieren Sie von einer Struktur, die Performance-Messungen und korrekte Initialisierungen bereits vormacht. Für große Hash-Benchmarks gibt es sogar dedizierte Demo-Projekte, die Laufzeiten für verschiedene Hashalgorithmen ausgeben (Large Hash Demo).

Sicherheits-Fallen in der Embedded-Realität: Was oft übersehen wird

Die häufigsten Sicherheitsprobleme bei AES/SHA auf Mikrocontrollern sind nicht „Algorithmus kaputt“, sondern Systemdesign und Umsetzung. Besonders relevant im PIC32-Kontext:

• Nonce/IV-Wiederverwendung: bei CTR/GCM der klassische Totalschaden.
• Fehlende Authentifizierung: „AES-verschlüsselt“ ohne MAC/AEAD schützt nicht vor Manipulation.
• Schlüssel im Klartext im Flash: oft die größte Schwachstelle, unabhängig von AES-256.
• Debug/Boot-Settings: Produktionsfuses, Debug-Ports, Bootloader-Regeln werden vergessen oder falsch dokumentiert.
• Eigenbau-Krypto: selbstgeschriebene AES/SHA-Implementationen ohne Testvektoren und Side-Channel-Bewusstsein sind ein Risiko.

Wenn Sie Netzwerkverschlüsselung umsetzen, lohnt zudem ein Blick in die Harmony-Netzwerkbeispiele, die TLS mit wolfSSL demonstrieren. Sie zeigen nicht nur AES/SHA in Isolation, sondern die Integration in einen vollständigen Kommunikations-Stack (Beispiel: wolfSSL TCP Client Demo).

Praxisbeispiele: Wo AES und SHA im PIC32-Alltag konkret eingesetzt werden

Zum Abschluss – ohne „Fazit“, aber mit Blick auf typische Anwendungsmuster – hier einige Szenarien, in denen AES und SHA auf PIC32-Projekten regelmäßig gebraucht werden:

• Firmware-Update mit Integritätscheck: SHA-256 über das Image, ggf. Signaturprüfung, danach optional verschlüsseltes Speichern sensibler Konfigurationsdaten.
• Verschlüsselte Telemetrie: AES-CTR für Daten, HMAC-SHA-256 für Integrität; Nonce aus Zähler + Geräte-ID.
• Lokaler Datenspeicher (SD/Flash): AES-CBC (mit korrektem IV) oder besser AEAD, um Manipulation zu erkennen.
• Transportverschlüsselung: TLS via wolfSSL; hier sind AES und SHA Teil eines größeren Handshakes samt Zertifikatsprüfung.
• Secure Element Integration: Schlüssel bleiben im Secure Element, PIC32 nutzt AES/SHA-Funktionen und erhält nur Ergebnisse (z. B. HMAC, Signatur-Verify).

Wer die Implementierung beschleunigen möchte, findet in Microchips Harmony-Ökosystem sowohl Bibliotheken als auch Demonstrationsprojekte, die AES, Hashing und weitere Krypto-Funktionen abdecken (Dokumentation: MPLAB Harmony Cryptographic Library; Beispiele: Encrypt/Decrypt Demo und Large Hash Demo). Damit erhalten Sie eine praxistaugliche Basis, auf der sich AES- und SHA-Funktionalität sauber, testbar und wartbar in PIC32-Firmware integrieren lässt.

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.