Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt
und werden im folgenden näher beschrieben. Es zeigen
: die Architektur eines Systems mit mehreren
Komponenten, bei denen einige mit dem sicheren Buscontroller ausgestattet sind;
und
: den inneren Aufbau eines sicheren Buscontrollers.
Jede Komponente (2), die über den Bus verschlüsselt
kommunizieren möchte, benötigt einen sicheren Buscontroller (1).
Dieser befindet sich direkt auf dem Chip der Komponente, so dass die unverschlüsselte
Kommunikation zwischen der Komponente und dem sicheren Buscontroller nicht abgehört
werden kann. Bei den Komponenten kann es sich um jeden beliebigen Chip, z. B. einen
Prozessor, einen RAM-Baustein oder einen Controller-Baustein handeln. Der sichere
Buscontroller nimmt die Daten von der jeweiligen Komponenten entgegen und entscheidet
anhand z. B. der Adresse, ob eine Verschlüsselung erforderlich ist. Durch diese
Entscheidungsmöglichkeit im Controller (5) ist sichergestellt, dass
auch mit Komponenten kommuniziert werden kann, welche nicht über einen sicheren
Buscontroller verfügen. Der sichere Buscontroller implementiert dabei das Interface
des jeweiligen Busses (4).
Da keine zusätzliche Verzögerung durch die Verschlüsselung
bedingt sein darf, muss diese taktsynchron mit dem aktuellen Buszyklus geschehen.
Aus diesem Grund ist nur eine on-the-fly-Verschlüsselung über eine Stromchiffre
(5) möglich.
Bevor die Kommunikation auf dem Bus verschlüsselt werden kann,
müssen sich alle sicheren Buscontroller auf einen gemeinsamen Schlüssel
als Initialisierung für die Stromchiffre einigen. Ein gemeinsamer Schlüssel
ist notwendig, damit jede Einheit beliebig mit anderen Einheiten kommunizieren kann.
Für den Schlüsselaustausch sind verschiedene Verfahren denkbar. Aufgrund
der begrenzten Ressourcen in einem Chip sollten jedoch besonders für den Hardwarebereich
optimierte Verfahren gewählt werden. Konkret lässt sich z. B. das Tree
Parity Machine-Verfahren für diesen Zweck einsetzen.
Bei der Initialisierung ist Kommunikation zwischen den sicheren Buscontrollern
erforderlich. Hierbei ist entscheidend, dass diese Kommunikation ebenfalls über
den vorhandenen Bus ablaufen kann, ohne Änderungen am Busprotokoll vornehmen
zu müssen. Erreicht wird dies, indem jeder sichere Buscontroller auf dem Bus
eine Adresse zugewiesen bekommt, unter der er erreichbar ist. Diese Adresse ist
unabhängig von der Adresse der Komponente, in der er sich befindet. Sollte
der Adressbereich eines Bussystems nicht ausreichen, um zusätzliche Adressen
für die sicheren Buscontroller zu vergeben, so ist es auch möglich, die
gesamte Kommunikation vor einem erfolgreichen Schlüsselaustausch als dedizierte
Kommunikation für die sicheren Buscontroller zu betrachten. Sobald der Schlüsselaustausch
vollzogen ist, schalten alle Einheiten dann in den normalen Kommunikationsmodus
um.
Einer der sicheren Buscontroller muss hierbei als Initiator des Schlüsselaustausches
fungieren. Da ein Bussystem in den häufigsten Fällen nicht dynamisch ist,
kann man die Initiatorkomponenten schon während der Entwicklung festlegen.
In den meisten Fällen wählt man hierfür die Komponente des Busses,
welche Master-Zugriff besitzt. Dies kann z. B. der Prozessor sein oder der Bus Arbiter.
Dies ist vorteilhaft, weil somit der Kommunikation während der Initialisierung
Vorrang gegeben werden kann. Die Logik für den Schlüsselaustausch wird
im Controller (5) innerhalb des sicheren Buscontrollers untergebracht
Solange die einzelnen sicheren Buscontroller sich noch nicht auf einen
gemeinsamen Schlüssel geeinigt haben, kann keine verschlüsselte Kommunikation
stattfinden. Da die Verschlüsselung jedoch transparent für die einzelnen
Komponenten ist, kann es sein, dass diese schon während einer noch laufenden
Initialisierung über den Bus kommunizieren möchten. In diesem Fall muss
der sichere Buscontroller alle Zugriffe auf Komponenten auf dem Bus, welche nur
verschlüsselt ausgeführt werden dürfen, verzögern bzw. in ihrer
Priorität herunterstufen, so dass die Komponente es zu einem späteren
Zeitpunkt noch einmal versucht. Dann könnte die Initialisierung eventuell schon
abgeschlossen sein.
Während des normalen Betriebes muss sichergestellt sein, dass
alle sicheren Buscontroller die Stromchiffre-Schlüssel kontinuierlich weiterschalten,
auch wenn sie gerade nicht aktiv an einer Übertragung beteiligt sind. Dies
ist erforderlich aufgrund der symmetrischen Gestalt der Architektur. Als gemeinsame
Signalisierung lassen sich z. B. Signale des Busses verwenden, die einen abgeschlossenen
Transfer kennzeichnen und an allen Einheiten am Bus verfügbar sind. Sollte
so ein Signal nicht zur Verfügung stehen, so kommt auch der gemeinsame Bustakt
als Synchronisationssignal in Frage.
Mit einfachen Mitteln lässt sich eine Authentifizierung realisieren.
Hierzu werden bei der Fertigung der Komponenten mit den sicheren Buscontrollern
spezielle nichtflüchtige Speicherzellen eingebaut, die später mit einem
Identifizierungsschlüssel belegt werden können. Ein Schlüssel kann
aber auch direkt bei der Fertigung in den Chip integriert werden. Während der
Initialisierungsphase wird diese Identifikationsinformation zum
Schlüsselaustausch verwendet. Sollte die Information nicht übereinstimmen,
so kann kein Schlüssel ausgetauscht werden. In Frage käme hierfür
z. B. die Authentifizierungsmöglichkeit beim Tree Parity Machine Schlüsselaustausch.
Jedoch auch ein Challenge-Response-Verfahren mit einer Hashfunktion ist einsetzbar.
Der Initiator muss dieses dann mit jedem einzelnen sicheren Buscontroller durchführen.
