DE102008013785A1

DE102008013785A1 - Vorberechneter Verschlüsselungsschlüssel

Info

Publication number: DE102008013785A1
Application number: DE102008013785A
Authority: DE
Inventors: Nhu-Ha Phoenix Yup
Original assignee: ITT Manufacturing Enterprises LLC
Current assignee: Exelis Inc
Priority date: 2007-03-12
Filing date: 2008-03-12
Publication date: 2008-09-18
Also published as: ES2364826A1; AU2008201156A1; DE102008013785A9; US9209967B2; GB0804483D0; GB2447552A; ES2364826B2; AU2008201156B2; US20100027783A1; ITTO20080186A1; GB2447552B

Abstract

Ein Authentifizierungsverschlüsselungsverfahren enthält Empfangen eines Chiffrierungsschlüssels mittels einer Fortgeschrittenen-Verschlüsselungs-Standard (AES)-Engine und Berechnen eines Hash-Schlüssels unter Verwendung des empfangenen Chiffrierungsschlüssels. Der berechnete Hash-Schlüssel wird in einem Speicher gespeichert. Dann empfängt die AES-Engine ein Datenpaket und verschlüsselt das Datenpaket unter Verwendung des empfangenen Chiffrierungsschlüssels. Der Hash-Schlüssel wird von dem Speicher an eine GHASH-Engine gesendet, die dazu verwendet wird, das Datenpaket zu authentifizieren. Das Verschlüsseln wird durchgeführt, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde. Der Eingangsfluss des Datenpaketes wird ermöglicht, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde.

Description

Die Erfindung betrifft insgesamt ein System und ein Verfahren zum Bereitstellen einer authentifizierten Verschlüsselung und Entschlüsselung. Insbesondere betrifft die Erfindung ein Verfahren zum Berechnen eines Verschlüsselungsschlüssels in einem System mit mehreren Kanälen eines Blockverschlüsselungsalgorithmus des fortschrittlichen Verschlüsselungsstandards ("advanced encryption standard") (AES).
Wenn zwei Kommunikationsteilnehmer miteinander kommunizieren, ist es oft erforderlich, dass sowohl die Geheimhaltung bzw. Privazität als auch die Authentizität der übertragenen Daten gewährleistet werden muss. Das Schützen der Privazität der Daten stellt sicher, dass nichtautorisierte Teilnehmer den Inhalt der Übertragungen nicht verstehen. Das Schützen der Authentizität der Daten schafft Sicherheit für den empfangenden Teilnehmer, dass der angebliche Sender der Nachricht auch der tatsächliche Sender der Nachricht ist. Es wird dadurch auch eine Sicherheit für den Empfänger geschaffen, dass die Nachricht bei der Übertragung nicht unbeabsichtigt oder vorsätzlich verändert wurde.
Bei einem Authentifizierungs-Verschlüsselungsverfahren verschlüsselt der Sender eine Nachricht unter Verwendung eines Schlüssels und einer Nonce (auch Initialisierungsvektor genannt, oder IV), um einen verschlüsselten Text zu gewinnen. Der Empfänger entschlüsselt den verschlüsselten Text unter Verwendung eines Schlüssels und einer Nonce, um daraus entweder eine Nachricht einer ein spezielles Ungültigkeitszeichen zu gewinnen, das dem Empfänger anzeigt, dass der verschlüsselt Text als nichtauthentisch betrachtet werden sollte.
Bei Nur-Geheimhaltungs-Verschlüsselung wird ein verschlüsselter Text aus einem Klartext, einem Schlüssel, und einer Nonce berechnet. Mittels eines Nachrichtenauthentifizierungscodes (MAC) wird ein Authentifizierungstag aus einer Nachricht und einem Schlüssel berechnet. Eine Nachricht mittels eines Nachrichtenauthentifizierungscodes zu verarbeiten bedeutet, ihr Authentifizierungstag unter Verwendung eines Nachrichtenauthentifizierungscodes zu berechnen.
Nebenbei, als ein weiterer Hintergrund, der Blockverschlüsselungsalgorithmus gemäß des fortschrittlichen Verschlüsselungsstandards (AES), oder die AES-Verschlüsselung, ist ein iterativer Verschlüsselungsalgorithmus, was bedeutet, dass Daten eine vorbestimmte Anzahl von Runden (Durchgängen) auf ähnliche Weise manipuliert werden. Die Blocklänge ist fest 128 Bits und die Schlüssellänge kann unabhängig auf 128, 192, oder 256 Bits gesetzt werden. Die AES-Verschlüsselung erlaubt auch eine veränderliche Anzahl (Nr) von Runden, die insgesamt 10, 12, oder 14 betragen kann und welche von der Blocklänge und der Schlüssellänge abhängt.
Bei der AES-Verschlüsselung wird ein Datenblock verschlüsselt, indem 9, 11, oder 13 vollständige Runden von Transformationen durchgeführt werden, gefolgt von einer finalen, unvollständigen Transformationsrunde. Die unvollständige Transformationsrunde enthält einen Schritt weniger als eine vollständige Transformationsrunde. Der Datenstring, d. h. die Datenzeichenfolge, die während jeder Runde gerade verarbeitet wird, wird ein "Zustand" genannt, der durch eine rechteckige Anordnung (Array) von Bytes mit vier Zeilen und einer Anzahl (Nb) von Spalten, die mit der Blocklänge variiert, dargestellt werden kann. Speziell ist der Wert von Nb gleich der Blocklänge (d. h. 128, 192, oder 256) geteilt durch 32, was bedeutet, dass er entweder 4, 6, oder 8 ist. Jede von den unvollständigen Runden enthält die folgenden vier Transformationen, die in der folgenden Reihenfolge durchgeführt werden: (1) ByteSub; (2) ShiftRow; (3) MixColumn; und (4) AddRoundKey. Diese vier Transformationen werden weiter unten erklärt. Die unvollständige Transformation enthält nicht die MixColumn-Transformation.
Ähnlich wie bei der Verschlüsselung werden Daten bei dem AES-Verfahren durch Durchführen derselben Anzahl von Runden, gefolgt von einer unvollständigen Runde, entschlüsselt. Weil die Verschlüsselungstransformationen umkehrbar sind, wird der Zustand jeder Entschlüsselungsrunde durch die Umkehrung der entsprechenden Transformation der oben genannten Transformationen durchgeführt. Außerdem erlauben die Eigenschaften der Transformationen und Umkehrtransformationen eine Symmetrie bei den Verschlüsselungs- und Entschlüsselungsalgorithmen. Mit anderen Worten, jede vollständige Entschlüsselungsrunde enthält die folgenden Umkehrtransformationen, welche in der Reihenfolge (1) InvByteSub; (2) InvShiftRow; (3) InvMixColumn; und (4) InvAddRoundKey durchgeführt werden können. Und wieder, ähnlich wie bei der Verschlüsselung, enthält die unvollständige Entschlüsselungsrunde nicht die InvMixColumn-Transformation.
Mehr Einzelheiten bezüglich der AES-Chiffrierung (AES cipher) sind in einer von dem Nationalen Institut von Standards und Technologie ("National Institute of Standards and Technology") (NIST) herausgegebenen Bundesveröffentlichung zu Informationsverarbeitungsstandards ("Federal Information Processing Standards Publication") (FIPS-PUBS) zu finden. Die Publikation ist der fortgeschrittene Verschlüsselungsstandard (AES) vom 26. November 2001, und kann über die Internetseite http://csrc.nist.gov/publications/ erhalten werden. Diese Publikation wird in ihrer Gesamtheit durch Bezugnahme hierin aufgenommen.
Die AES-Kodierung unterstützt unterschiedliche Operationsmoden, einschließlich der Chiffrierungsblockverkettung ("cipher block chaining") (CBC), dem elektronischen Codebuch ("electronic codebook") (ECB), und dem Galoiszählermodus ("Galois counter mode") (GCM). Der Galoiszählermodus ist ein Blockchiffrierungsverfahren, das eine Hash-Wert-Berechnung über einem binären Galois-Feld verwendet, um eine authentifizierte Verschlüsselung zu schaffen. Das ausführliche Dokument mit dem Titel "The Galois/Counter Mode of Operation (GCM)" ist auf csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf zu finden. Diese Publikation ist in ihrer Geamtheit auch hierin mittels Bezugnahme aufgenommen.
Ein herkömmliches GCM-AES-Blockchiffrierungssystem enthält eine Verschlüsselung, die in 10, 12, oder 14 Runden unter Verwendung von Rundenschlüsseln durchgeführt wird. Ein Hash-Schlüssel wird aus den Rundenschlüsseln berechnet, um eine authentifizierte Verschlüsselung bzw. Authentifizierungsverschlüsselung für jeden Rahmen oder jedes Paket zu schaffen, das zu einem fernen Empfänger übertragen wird. Dies erfordert 10, 12, oder 14 Taktzyklen für jeden Rahmes oder jedes Paket, das durch den Sender übertragen wird. Auf ähnliche Weise benötigt der Empfänger für jeden Rahmen oder jedes Paket 10, 12, oder 14 Taktzyklen, um den Hash- Schlüssel aus den Rundenschlüsseln zu berechnen. Dies hat unvorteilhafterweise einen erhöhten Durchsatz und Verzögerungen durch den Prozessor beim Authentifizieren des entsprechenden Rahmens oder Pakets zu Folge. Die Erfindung beschäftigt sich mit dieser Unzulänglichkeit und stellt als ein Aspekt der Erfindung eine entsprechende Lösung bereit.
Um diese und andere Anforderungen zu erfüllen, schafft die Erfindung im Hinblick auf ihre Zwecke ein Authentifizierungsverschlüsselungsverfahren. Dieses Verfahren enthält die folgenden Schritte: (a) Empfangen eines Chiffrierungsschlüssels mittels einer Fortgeschrittenen-Verschlüsselungs-Standard (AES)-Engine (bzw. eine AES-Maschine); (b) Berechnen, mittels der AES-Engine, eines Hash-Schlüssels unter Verwendung des empfangenen Chiffrierungsschlüssels; (c) Speichern des berechneten Hash-Schlüssels in einem Speicher; (d) Empfangen eines Datenpakets mittels der AES-Engine; (e) Verschlüsseln, mittels der AES-Engine, des Datenpaktes unter Verwendung des empfangenen Chiffrierungsschlüssels; (f) Empfangen des Hash-Schlüssels aus dem Speicher durch eine GHASH-Engine (bzw. GHASH-Maschine); und (g) Authentifizieren des Datenpakets, mittels der GHASH-Engine, unter Verwendung des Hash-Schlüssels. Der Verschlüsselungsschritt enthält Verwenden eines Zählermodus in der AES-Engine, um das Datenpaket zu verschlüsseln. Verwenden des Zählermodus enthält iteratives Anwenden einer XOR-Funktion auf (a) einen Klartextbereich des Datenpakets mit (b) einem verschlüsselten Wert von Zählerdaten unter Verwendung des Chiffrierungsschlüssels und dadurch Gewinnen eines Daten-Chiffrierungstextes (ciphertext). Der Authentifizierungsschritt enthält Übertragen des Chiffrierungstextes an die GHASH-Engine, um iteratives Multiplizieren des Chiffrierungstextes durch die GHASH-Engine unter Verwendung des Hash-Schlüssels. Das Verschlüsseln des Datenpakets wird durchgeführt, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde.
Nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde, wird der Eingangsfluss des Datenpaktes freigegeben. Das Datenpaket wird unter Verwendung des Verschlüsselungsschlüssels verschlüsselt, und nach der Freigabe des Eingangsflusses des Datenpakets wird das Datenpaket unter Verwendung des in dem Speicher gespeicherten Hash-Schlüssels authentifiziert.
Der Hash-Schlussel wird berechnet, indem 10 Runden von Schlüsselerweiterungen bzw. Schlüsselexpansionen des empfangenen Chiffrierungsschlüssel durchgeführt werden, falls der empfangene Chiffrierungsschlüssel ein 128-Bit-Datenblock ist; und indem 12 Runden von Schlüsselerweiterungen des empfangenen Chiffrierungsschlüssels durchgeführt werden, falls der empfangene Chiffrierungsschlüssel ein 192-Bit-Datenblock ist; und indem 14 Runden von Schlüsselerweiterungen durchgeführt werden, falls der empfangene Chiffrierungsschlüssel ein 256 Bit-Datenblock ist.
Das Verfahren der Erfindung enthält Empfangen von mindestens zwei separaten Chiffrierungsschlüsseln aus entsprechenden Datenkanälen, und Berechnen von mindestens zwei separaten Hash-Schlüsseln, die mit den mindestens zwei separat empfangenen Chiffrierungsschlüsseln korrespondieren. Das Empfangen des Datenpakets enthält Empfangen einer vorbestimmten Anzahl von Datenpaketen während eines Zeitintervalls. Das Berechnen des Hash-Schlüssels enthält Berechnen des Schlüssels einmal in jedem der Zeitintervalle, und das Speichern des Berechneten Hash-Schlüssels enthält Speichern des Berechneten Hash-Schlüssels einmal in jedem der Zeitintervalle.
Ein anderes Ausführungsbeispiel der Erfindung enthält ein Authentifizierungsverschlüsselungsmodul. Das Verschlüsselungsmodul enthält eine AES-Engine zur Verwendung eines Chiffrierungsschlüssels, um einen Hash-Schlüssel zu berechnen, einen Speicher zum Speicher des berechneten Hash-Schlüssels, und eine GHASH-Engine zum Empfangen des berechneten Hash-Schlüssels, der in dem Speicher gespeichert ist, zum Authentifizieren eines Datenpakets. Die AES-Engine verschlüsselt das Datenpaket, um einen Chiffrierungstext zu erzeugen. Die GHASH-Engine empfängt den Chiffrierungstext aus der AES-Engine, um den empfangenen Chiffrierungstext mit dem berechneten Hash-Schlüssel zu multiplizieren. Ein Authentifizierungstag wird unter Verwendung des mit dem berechneten Hash-Schlüssels multiplizierten Chiffrierungstextes berechnet. Eine Steuerungseinheit gibt den Eingangsfluss des Datenpakets frei, nachdem der berechnete Hash-Schlüssel in dem Speicher gespeichert wurde. Das Datenpaket enthält zusätzliche authentifizierte Daten (zusätzliche Authentifizierungsdaten) (AAD), und die GHASH-Engine ist dazu gestaltet, die AAD zu empfangen, um die AAD mit dem berechneten Hash-Schlüssel zu multiplizieren.
Die AES-Engine ist dazu gestaltet, mindestens zwei unterschiedliche Verschlüsselungsschlüssel aus entsprechenden Datenkanälen zu empfangen. Die AES-Engine enthält zwei Verschlüsselungsmodule zum Verschlüsseln von mindestens zwei unterschiedlichen Datenpaketen, die unter Verwendung der mindestens zwei unterschiedlichen Verschlüsselungsschlüssel aus den entsprechenden Datenkanälen empfangen wurden. Das Datenpaket enthält mehrere Datenpakete, und der Hash-Schlüssel wird einmal berechnet für alle von den mehreren empfangenen Datenpaketen. Der Hash-Schlüssel wird einmal gespeichert für alle von den mehreren empfangenen Datenpaketen.
Es sollte verstanden werden, dass die vorgehende allgemeine Beschreibung und die folgende ausführliche Beschreibung beispielhaft, aber nicht einschränkend, für die Erfindung sind.
Die Erfindung kann am besten verstanden werden, wenn die folgende ausführliche Beschreibung in Verbindung mit den beigefügten Zeichnungen gelesen wird:
1 ist ein Funktionsblockdiagramm, dass ein beispielhaftes Verschlüsseln und Authentifizieren eines Pakets (oder Rahmens) von Daten zeigt.
2 ist ein Funktionsblockdiagramm, dass ein beispielhaftes Entschlüsseln und Authentifizieren eines verschlüsselten Pakets (oder Rahmens) von Daten zeigt.
3 ist ein Blockdiagramm eines AES-GCM-Verschlüsselungsmoduls mit einem externen SA-Speicher in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung.
4 ist ein Funktionsblockdiagramm einer Authentifizierungsverschlüsselungsoperation, das eine Blockchiffrierungs-Verschlüsselung und -Multiplikation über einem Galois-Feld zeigt.
5 ist ein Funktionsblockdiagramm einer Authentifizierungsentschlüsselungsoperation, das eine Blockchiffrierungs-Entschlüsselung und -Multiplikation über dem Galois-Feld zeigt.
6 ist ein Blockdiagramm eines AES-Engine-Moduls in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung, das vier Eingangsdatenfluss-Kanäle und zwei Chiffrierungstransformationsmodule enthält.
7 ist ein Blockdiagramm einer GHASH-Engine in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung.
8 ist ein Flussdiagramm, das ein Verfahren zum Authentifizieren eines Datenpakets in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung zeigt.
9 ist ein Flussdiagramm eines Verfahrens zum Authentifizieren eines verschlüsselten Datenpakets in Übereinstimmung mit einem exemplarischen Ausführungsbeispiel der Erfindung.
Die Erfindung enthält einen AES-GCM-Operationsmodus. Der GCM enthält zwei Operationen, Authentifizierungsverschlüsselung und Authentifizierungsentschlüsselung. Die Authentifizierungsverschlüsselung hat vier Eingaben, wobei jede eine Bitzeichenfolge ist, und zwar:

(1) einen geheimer Schlüssel K, dessen Länge für die zugrunde liegende Blockchiffrierung geeignet ist;
(2) einen Initialisierungsvektor IV (Nonce);
(3) einen Klartext P; und
(4) zusätzliche Authentifizierungsdaten (AAD), bezeichnet als A. Diese Daten sind authentifiziert, aber nicht verschlüsselt.

Die Authentifizierungsverschlüsselungsoperation hat zwei Ausgaben, und zwar:

(1) einen Chiffrierungstext C, dessen Länge exakt gleich der des Klartextes P ist; und
(2) einen Authentifizierungstag T. Die Länge des Tags wird als t bezeichnet.

Falls die Blockchiffrierungsbreite ist. Die Authentifizierungsentschlüsselungsoperation, und Länge() ist die Bitanzahl in einem Argument, dann gilt
0 ≤ Länge(P) ≤ (2³² – 2)w,
0 ≤ Länge(A) ≤ 2^w/2
0 ≤ Länge(IV) ≤ 2^w/2
Länge(C) = Länge(P), und
Länge(T) = t ≤ w.
Eine beispielhafte Verschlüsselung und Authentifizierung eines Pakets (oder Rahmens) von Daten ist in 1 gezeigt. Wie gezeigt wird, enthält das Eingangspaket 11 ein Dateikopffeld (header field), ein Sequenzfeld, und ein Klartextdatenfeld. Das Datenfeld wird durch das GCM-Verschlüsselungsmodul 12 verschlüsselt und authentifiziert. Das Dateikopffeld kann in dem GCM-Verschlüsselungsmodul authentifiziert werden, indem es in das AAD-Feld aufgenommen wird. Das Sequenzfeld kann in dem IV enthalten sein und an das GCM-Verschlüsselungsmodul gesendet werden. Das Paket 11 wird somit von dem GCM-Verschlüsselungsmodul verschlüsselt und authentifiziert. Das ausgegebene Paket, als Paket 13 dargestellt, wird an den Empfänger übertragen und enthält (1) das verschlüsselte Datenfeld, (2) das Authentifizierungstag, das in dem Integritätsprüfsummen (ICV)-Feld transportiert wird, und das (3) Dateikopffeld und das (4) Sequenzfeld, welche beigefügt sind.
Indem die Sequenzzahl in den IV aufgenommen wurde, wird die Anforderung, dass die IV-Werte eindeutig sind, erfüllt. Die Daten, die den IV bilden, müssen bekannt sein sowohl für die Verschlüsselungsseite als auch für die Entschlüsselungsseite, aber der IV muss nicht in dem Paket enthalten sein und kann separat gesendet werden. Es wird geschätzt werden, dass die Länge des Klartextes des eingehenden Pakets 11 gleich ist der Länge des Chiffrierungstextes des ausgehenden Pakets 13.
Nun bezugnehmend auf 2, in 2 wird ein GCM-Entschlüsselungsmodul 16 gezeigt, das das empfangene Eingangspaket 15 entschlüsselt und dessen Authentizität verifiziert. Das GCM-Verschlüsselungsmodul entschlüsselt den Chiffrierungstext, um den Klartext des ausgehenden Paktes 17 bereitzustellen. Das Authentifizierungstag wird mit einem intern berechneten Authentifizierungstag verglichen, um die Authentizität des Eingangspakets 15 zu verifizieren. Das finale Ausgangspaket enthält das Dateikopffeld und das Sequenzfeld, wie gezeigt wird.
Die Authentifizierungsentschlüsselungsoperation hat fünf Eingaben: K, IV, C, A, und T. Die Authentifizierungsentschlüsselungsoperation hat nur eine einzige Ausgabe, entweder den Klartextwert P oder ein Sondersymbol FAIL ("Fehlgeschlagen"), das angibt, dass die Eingangsdaten nicht authentisch sind. Der Chiffrierungstext, der Initialisierungsvektor IV, die zusätzlichen Authentifizierungsdaten A, und das Tag T sind authentisch für den Schlüssel K, wenn sie durch die Verschlüsselungsoperation des GCM-Verschlüsselungsmoduls 12 mit den Eingaben K, IV, A, und dem Klartext P erzeugt wurden. Die Authentifizierungsentschlüsselungsoperation des GCM-Entschlüsselungsmoduls 16 gibt mit hoher Sicherheit FAIL aus, wenn die Eingaben nicht mit dem identischen Schlüssel durch die Verschlüsselungsoperation erzeugt wurden.
Die zusätzlichen Authentifizierungsdaten A werden dazu verwendet, die Information zu schützen, die authentifiziert werden muss, die aber unverschlüsselt bleiben muss. Wenn GCM verwendet wird, um ein Netzwerkprotokoll zu sichern, können die Daten A Adressen, Ports, Sequenznummern, Protokollversionsnummern, und andere Felder enthalten, die angeben, wie der Klartext gehandhabt, weitergeleitet, und verarbeitet werden soll. In vielen Situationen ist es wünschenswert, diese Felder zu authentifizieren, obgleich sie in Klartextform belassen werden, um dem Netzwerk oder dem System zu erlauben, richtig zu funktionieren. Wenn diese Daten in dem AAD enthalten sind, ist eine Authentifizierung ohne ein Kopieren in den Chiffrierungstext vorgesehen.
Der primäre Zweck des IV ist es, eine Nonce zu sein, das heißt, eindeutig zu sein für einen festen Schlüssel für jeden Aufruf der Verschlüsselungsoperation. Es ist für den IV akzeptabel, zufällig erzeugt zu werden, solange die Eindeutigkeit der IV-Werte hochwahrscheinlich ist. Der IV wird authentifiziert, und es ist nicht notwendig, ihn in das AAD-Feld aufzunehmen.
Die Strenge der Authentifizierung der P, IV, und A wird durch die Länge t des Authentifizierungstags bestimmt. Wenn die Länge von P Null ist, dann wirkt die GCM für die Eingabe A als MAC. Der Operationsmodus, der GCM als einen alleinigen Nachrichtenauthentifizierungscode verwendet, wird als GMAC bezeichnet.
Die Gleichungen, die von dem in 1 gezeigten GCM-Verschlüsselungsmodul 12 verwendet werden, werden nun beschrieben. Im Folgenden wird angenommen, dass die Chiffrierungsblockbreite w 128 Bits beträgt.
Bezeichne n und u ein Paar von positiven ganzen Zahlen, so dass die gesamt Anzahl von Bits in dem Klartext (n – 1)·128 + u beträgt, wobei 1 ≤ u ≤ 128 ist. Der Klartext besteht aus einer Sequenz von n Bitzeichenfolgen, in welchen die Bitlänge (Bitanzahl) der letzten Bitzeichenfolge u ist und die Bitlänge der anderen Bitzeichenfolgen 128 ist. Die Sequenz wird mit P₁, P₂, ..., P_n-1, P*_n bezeichnet, und die Bitzeichenfolgen werden Datenblöcke genannt, obgleich es sein kann, dass die letzte Bitzeichenfolge P*_n kein vollständiger Block ist. Ähnliche wird der Chiffrierungstext mit C₁, C₂, ..., C_n-1, C*_n bezeichnet, wobei die Anzahl der Bits in dem finalen bzw. letzten Block C*_n u ist. Die zusätzlichen Authentisierungsdaten A werden mit A₁, A₂, ..., A_m-1, A*_m bezeichnet, wobei es sein kann, dass die letzte Bitzeichenfolge A*_m ein Teilblock der Länge v ist, und m und v bezeichnen ein Paar von positiven ganzen Zahlen, so dass die gesamte Anzahl von Bits (m – 1)·128 + v beträgt und l ≤ v ≤ 128 ist.
Die Authentifizierungsverschlüsselungsoperation wird durch die folgenden Gleichungen definiert, wobei w als Blockchiffrierungsbreite verwendet wird: H = E(K, 0w) Y0 = IV||0311falls Länge(IV) = w – 32 Y0 = GHASH(H, {}, IV)andernfalls Yi = incr(Yi-1)für i = 1, ..., n Ci = Pi ⊕ E(K, Yi)für i = 1, ..., n – 1 C*n = P*n ⊕ MSBu(E(K, Yn)) T = MSBt(GHASH(H, A, C) ⊕ E(K, Y0))
Es werden sukzessiv Zählerwerte erzeugt unter Verwendung der Funktion incr(), welche die 32 am weitesten rechts stehen Bits ihres Arguments als nichtnegative ganze Zahl behandelt, mit dem am wenigsten signifikanten Bit auf der rechten Seite, und welche diesen Wert modulo 2³² inkrementiert.
Die Funktion Länge() ergibt eine 64-Bit-Zeichenfolge, die die nichtnegative ganze Zahl beschreibt, die die Anzahl der Bits in ihrem Argument enthält, wobei das am wenigsten signifikante Bit auf der rechten Seite bzw. ganz rechts steht. Der Ausdruck 0^l bezeichnet eine Zeichenfolge von l Nullbit, und A||B bezeichnet die Konkatenation von zwei Bitzeichenfolgen A und B. Die Funktion MSB_t(S) ergibt die Bitzeichenfolge, die nur die t signifikantesten (d. h. am weitesten links stehenden) Bits von S ergibt, und das Symbol {} bezeichnet die Bitzeichenfolge mit der Länge Null.
Die Funktion GHASH ist definiert durch GHASH (H, A, C) = X_m+n+l, wobei die Eingaben A und C wie oben beschrieben formatiert sind, und die Variablen X_i für i = 0, ..., m + n + l sind wie folgt definiert: Xi = 0i = 0 Xi = (Xi-1 ⊕ Ai)·Hi = 1, ..., m – 1 Xi = (Xm-1 ⊕ (A*m ||0w-v))·Hi = m Xi = (Xi-1 ⊕ Ci-m)·Hi = m + 1, ..., m + m – 1 Xi = (Xm+n-1 ⊕ (C*m ||0w-v))·Hi= m + n Xi = (Xm +n ⊕ (Länge(A)||Länge(C)))·Hi = m + n + 1
Die Authentifizierungsentschlüsselungsoperation ist ähnlich der Verschlüsselungsoperation, aber mit der Ordnung des Hash-Schrittes und des Verschlüsselungsschrittes invertiert. Mehr formal ausgedrückt, sie ist durch die folgenden Gleichungen definiert: H = E(K, 0w) Y0 = IV||0311falls Länge(IV) = w – 32 Y0 = GHASH(H, {}, IV)andernfalls T' = MSBt(GHASH(H, A, C) ⊕ E(K, Y0)) Y = incr(Yi-1)für i = 1, ..., n Pi = Ci ⊕ E(K, Yi)für i = 1, ..., n – 1 P*n = C*n ⊕ MSBu(E(K, Yn))
Das Tag T', welches durch die Entschlüsselungsoperation berechnet wurde, wird mit dem Tag T verglichen, das mit dem Chiffrierungstext C assoziiert ist. Falls die zwei Tags übereinstimmen (in sowohl der Länge als auch ihrem Wert), dann wird der Chiffrierungstext zurückgegeben. Andernfalls wird das Symbol FAIL zurückgegeben.
Nun wird auf 3 Bezug genommen, dort wird ein Funktionsblockdiagramm eines AES-GCM-Verschlüsselungsmoduls gezeigt, das insgesamt mit 30 bezeichnet wird. Der SA-Speicher 34, der extern zu dem AES-GCM-Modul ist, speichert den Verschlüsselungsschlüssel K und den Hash-Schlüssel H. Wie oben beschrieben, ist H = E(K, 0w),welches die Blockchiffrierungsverschlüsselung des Werts 0^w mittels des Schlüssels K ist.
Der Verschlüsselungsschlüssel K wird an die AES-Engine 31 geliefert, und der Hash-Schlüssel H wird an die GHASH-Engine 32 geliefert. Die finite Zustandsmaschine (FSM), insgesamt bezeichnet mit 33, empfängt eingehende Steuerungssignale und steuert das AES-GCM-Modul 30. Die AES-Engine 31 kann in dem Elektronischen-Codebuch (ECB)-Modus und dem Chiffrierungsblockverkettungs (CBC)-Modus betrieben werden, und der Zähler (CTR)-Bereich des GCM kann sowohl für eine Verschlüsselung als auch für eine Entschlüsselung betrieben werden. Die AES-Engine unterstützt verschiedene Schlüsselblockgrößen, einschließlich 128 Bits, 192 Bits, und 256 Bits.
Die AES-Engine führt einen Algorithmus aus, der Operationen hat, die über einem zweidimensionalen Array aus Bytes, Zustand genannt, durchgeführt werden. Der Zustand besteht aus vier Zeilen von Bytes, von denen jede Nb Bytes enthält, wobei Nb die Blocklänge geteilt durch 32 ist. Der Zustand enthält eine Eingabe und eine Ausgabe. Beim Start des Chiffrierens und umgekehrten Chiffrierens wird die Eingabe, welche das Array von Eingabebytes ist, in das Zustandsarray kopiert. Die Chiffrierungs- und Umkehr-Chiffrierungs-Operationen werden dann über diesem Zustandsarray ausgeführt, nachdem dessen finaler Wert in die Ausgabe kopiert wurde, welche ein anderes Array aus Ausgabebytes ist.
Für den AES-Engine-Algorithmus beträgt die Länge des Eingabeblocks, des Ausgabeblocks, und des Zustands 128 Bits.
Dies wird repräsentiert durch Nb = 4, was die Anzahl der 32-Bit-Worte (Anzahl von Spalten) widerspiegelt. Die Länge des Chiffrierungsschlüssels, K, beträgt 128, 192, oder 256 Bits. Die Schlüssellänge wird repräsentiert durch Nk = 4, 6, oder 8, was die Anzahl der 32-Bit-Worte (Anzahl von Spalten) in dem Chiffrierungsschlüssel widerspiegelt. Die Anzahl der während der Ausführung des Algorithmus durchgeführten Runden ist abhängig von der Schlüsselgröße. Die Anzahl der Runden wird repräsentiert durch Nr, wobei Nr = 10 ist, wenn Nk = 4 ist, Nr = 12 ist, wenn Nk = 6 ist, und Nr = 14 ist, wenn Nk = 8 ist.
Für sowohl seine Chiffrierung als Umkehrchiffrierung verwendet der AES-Engine-Algorithmus eine Runden-Funktion, die aus vier unterschiedlichen Byte-orientierten Transformationen zusammengesetzt ist: (1) Byte-Ersetzung unter Verwendung einer Ersetzungstabelle (S-Kasten) (SubBytes), (2) Schieben von Zeilen des Zustandsarrays mit unterschiedlichen Offsets (ShiftRows), (3) Mischen der Daten innerhalb jeder Spalte des Zustandsarrays (MixColumns), und (4) Hinzufügen eines Rundenschlüssels zu dem Zustand (AddRoundkey). Diese Transformationen (und deren Umkehrungen) werden in der AES-Standard-Veröffentlichung, auf die oben Bezug genommen wurde, beschrieben und sind hierin mittels Bezugnahme aufgenommen. Die Schlüsselblockrunden-Kombinationen sind in der folgenden Tabelle zusammengefasst:

Schlüssellänge (Nk Worte) Blockgröße (Nb Worte) Anzahl von Runden (Nr) Takt-Perioden

AES-128 4 4 10 10

AES-192 6 4 12 12

AES-256 8 4 14 14
Nach dem Start der Chiffrierung wird die Eingabe in den das Zustandsarray kopiert, wie oben beschrieben wurde. Nach einer initialen Rundenschlüssel-Hinzufügung wird das Zustandsarray durch 10-, 12-, oder 14-maliges (abhängig von der Schlüssellänge) Implementieren einer Rundenfunktion transformiert, wobei die finale Runde sich leicht von den ersten Nr-1 Runden unterscheidet. Der finale Zustand wird dann in die Ausgabe kopiert, wie oben beschrieben.
Wie beschrieben wurde, enthält das Chiffrieren vier Transformationen. Diese individuellen Transformationen-SubBytes(), ShiftRows(), MixColumns(), und Addroundkey() – verarbeiten den Zustand. Alle Nr Runden sind identisch, mit Ausnahme der finalen Runde, welche nicht die MixComuns()-Transformation enthält.
Es wird geschätzt werden, dass die oben erwähnte Chiffrierung umgekehrt werden kann und dann in der umgekehrten Reihenfolge implementiert werden kann, um eine inverse Chiffrierung für den AES-Engine-Algorithmus zu erzeugen. Die individuellen Transformationen, die in der Umkehrchiffrierung verwendet werden – InvShiftRows(), InvSubBytes, InvMixColumns(), und AddRoundkey() – verarbeiten den Zustand und werden in der AES-Standard-Veröffentlichung beschrieben.
Die Erfindung berechnet, falls die Schlüsselgröße 128 Bits beträgt, den Hash-Schlüssel H unter Verwendung der AES-Engine durch Ausführen von 10 Berechnungsrunden (10 Taktperioden bzw. 10 Taktzyklen). Nachdem die letzte Runde berechnet wurde, wird der Hash-Schlüssel H zum Speichern zu dem SA-Speicher 34 gesendet. Ähnlich berechnet die Erfindung, falls die Schlüsselgröße 192 Bits beträgt, den Hash-Schlüssel durch Ausführen von 12 Berechnungsrunden (12 Taktperioden) und dann Speichern des Hash-Schlüssels in dem SA-Speicher 34. Ferner berechnet die Erfindung, falls die Schlüsselgröße 256 Bits beträgt, den Hash-Schlüssel unter Verwendung von 14 Berechnungsrunden (14 Taktperioden). Nach der letzten Runde wird gemäß der vorliegenden Erfindung der Hash-Schlüssel in dem SA-Speicher gespeichert.
Die AES-Engine ist vorteilhafterweise dazu programmiert, den Hash-Schlüssel vor der Zeit des Austauschens zwischen dem Sender und dem Empfänger zu berechnen. Solche Vorberechnungen sparen 10, 12, oder 14 Taktzyklen pro Paket (oder Rahmen), welche anderenfalls erforderlich wären, um den Hash-Schlüssel H für des Paket oder jeden Rahmen zu berechnen.
Als nächstes wird, auf 4 Bezug nehmend und die Authentifizierungsverschlüsselungsgleichungen wiederaufgreifend, die Art und Weise, mit der das Authentifizierungstag bestimmt wird, durch die insgesamt mit 40 bezeichnete Authentifizierungsverschlüsselungsoperation beispielhaft erläutert. Die Authentifizierungsoperation 40 enthält zwei in dem GCM verwendete Hauptfunktionen, welche die Blockchiffrierungsverschlüsselung und die Multiplikation über dem Feld GF(2¹²⁸) sind. Wie gezeigt wird, bezeichnet die Funktion E_k (siehe die Bezugszeichen 43a, 43bm und 43c) die Blockchiffrierungsverschlüsselung unter Verwendung des Schlüssels K. Die Funktion mult_H (siehe die Bezugszeichen 44a, 44b, 44c, und 44d) bezeichnet die Multiplikation in GF (2¹²⁸) mit dem Hash-Schlüssel H. Die incr-Funktion (siehe die Bezugszeichen 41a und 41b) bezeichnet die Zähler (CTR)-Inkrementier-Funktion. Zur Vereinfachung werden nur ein einziger Block von zusätzlichen Authentifizierungsdaten (bezeichnet als Auth Daten 1) und zwei Klartext-Blöcke (bezeichnet als Klartext 1 und Klartext 2) gezeigt.
Die Addition von zwei Elementen X und Y in GF (2¹²⁸) besteht aus einem Addieren eines Polynoms, das X repräsentiert, zu einem anderen Polynom, das Y repräsentiert. Diese Operationen sind zum Ausführen der bitweisen exklusiven ODER (XOR) Funktion von X und Y identisch. Die XOR-Operationen werden in 4 mit XOR 45a bis XOR 45f bezeichnet. Die Multiplikation von zwei Elementen X und Y besteht aus dem Multiplizieren eines Polynoms, das X repräsentiert, mit einem Polynom, das Y repräsentiert, und dann Teilen des resultierenden 256-Bit-Polynoms durch ein Feld-Polynom, wobei ein 128-Bit-Rest das Ergebnis ist. Das Feld-Polynom ist fest und bestimmt die Darstellung des Feldes. Das GCM verwendet das Polynom f = 1 + α + α² + α⁷ + α¹²⁸.
Unter Bezugnahme auf 4 bezeichnet CTR 41a, b insgesamt die Y_i-Zählerausgabe, welche in dem Modul 43b, c mit dem Verschlüsselungsschlüssel K verschlüsselt wird. Auf die verschlüsselte Ausgabe wird mit dem Klartext 1, 2 die XOR-Funktion angewandt, wodurch der Chiffrierungstext 1, 2 gewonnen wird. Separat wird der CTR-Zustand Y₀ (Zähler 0) durch das Modul 43a verschlüsselt, um E(K, Y₀) zu gewinnen. Die Authentifizierungsdaten (Auth Daten) 1 werden weiter verarbeitet durch mult_H (44a), und dann wird die XOR-Funktion mit dem Chiffrierungstext 1 auf sie angewandt, welcher dann weiter verarbeitet wird durch mult_H (44c). Auf die Ausgabe aus mult_H (44c) wird mit der Konkatenation der Bits A und C die XOR-Funktion angewandt, auf die final mit E(K, Y₀) die XOR-Funktion angewandt wird, um das Authentifizierungstag T zu gewinnen, wie weiter oben beschrieben wurde. Es wird geschätzt werden, dass die weiter oben beschriebene Variable X aus den iterativen Operationen des Multiplizierens des Hash-Schlüssels H mit dem Chiffrierungstext oder den AAD stammt. Die GHASH-Funktion wiederrum ist definiert durch GHASH(H, A, C) = X_i.
Als nächstes wird mit dem Verfahren 50, auf 5 Bezug nehmend und die Authentifizierungsentschlüsselungsgleichungen wiederaufgreifend, die Art und Weise gezeigt, wie das Authentifizierungstag während der Entschlüsselungsoperation gewonnen wird. Das Verfahren 50 ist ähnlich zu dem Verfahren 40, mit der Ausnahme, dass der Chiffrierungstext, wenn die XOR-Funktion mit der Ausgabe des E_k-Moduls auf ihn angewandt wird, den Klartext ergibt. Wie gezeigt wird, erzeugt das E_k-Modul (bezeichnet mit 53a, 53b, 53c) die Blockchiffrierungsentschlüsselung unter Verwendung des Schlüssels K. Die mult_H-Funktion (siehe die Bezugszeichen 54a, 54b, 54c, und 54d) bezeichnet eine Multiplikation in GF (2¹²⁸) mit dem Hash-Schlüssel H. Die incr-Funktion (siehe die Bezugszeichen 51a und 51b) bezeichnet die Zähler (CTR)-Inkrementier-Funktion. Zur Vereinfachung werden nur ein einziger Block von zusätzlichen Authentifizierungsdaten (bezeichnet mit Auth Daten) und zwei Blöcke von Chiffrierungstext (bezeichnet als Chiffrierungstext 1 und Chiffrierungstext 2) gezeigt.
Ein exemplarisches Blockdiagramm eines AES-Engine-Moduls, insgesamt bezeichnet mit 60, wird in 6 gezeigt. Das AES-Engine-Modul enthält vier Kanäle von Datenfluss, welche sich die zwei Chiffrierungstransformationsmodule teilen. Die zwei Chiffrierungstransformationsmodule als mit dem Bezugszeichen 70a und 70b gezeigt. Es wird verstanden werden, dass bis zu vier Chiffrierungstransformationsmodule enthalten sein können, so dass jeder der vier Kanäle sein eigenes Chiffrierungstransformationsmodul hat. Vier Eingangsregister 82 werden in der Figur gezeigt. Die Eingangsregister 82 sind First-in-first-out (FIFO)-Register, obgleich auch andere Typen verwendet werden können. Die Eingangsregister empfangen jedes eine Datenzeichenfolge mit einer vorbestimmten ersten Bitlänge jeweils aus deren korrespondierenden Systemkanal. In dem exemplarischen Ausführungsbeispiel beträgt die vorbestimmte Bitlänge (bezeichnet mit 85) 64 Bits, obgleich auch längere Datenzeichenfolgen verwendet werden können.
Die Steuerungssignale 83, der Schlüssel 84 (ein Schlüsseldatum pro Kanal), und die Zustandsarraypuffer (SAIB)-Steuerungen (auch 84) werden als eingehende Signale an das AES-Engine-Modul 60 geliefert. Die Steuerungssignale werden ein jedes mit vier finiten Zustandsmaschinen-Steuerungseinheiten (FSMs) 76 gekoppelt. Mit jedem Kanal ist eine FSM 76 assoziiert, von denen jede in Antwort auf die empfangenen Steuerungssignale den Betrieb des AES-Engine-Moduls 60 steuert.
Die Eingangsregister 82 sind mit Pufferregistern 80a, 80b gekoppelt. Jedes Pufferregister fragt ab und speichert selektiv, unter Steuerung von einem der FSMs, Datenzeichenfolgen einer vorbestimmten Länge aus einem von den FIFO-Registern 82, solange bis ein Datenblock mit einer vorbestimmten Bitlänge in den Puffereingangs-FIFO-Registern 80a, 80b (BIF-Register 80a, 80b) gespeichert ist. Die vorbestimmte Bitlänge des Datenblocks ist eine Blocklänge, die durch die AES-Blockchiffrierung unterstützt wird, nämlich die Länge von 128 Bits.
Das AES-Engine-Modul 60 enthält für jeden Systemkanal ein Chiffrierungsschlüssel-Speicherregister 81. Das Chiffrierungsschlüssel-Speicherregister 81 empfängt aus dem SA den mit jedem Systemkanal (vier Kanäle) assoziierten Chiffrierungsschlüssel K. Unter der Steuerung seines entsprechenden FSM überträgt das Chiffrierungsschlüssel-Speicherregister den gespeicherten Chiffrierungsschlüssel K an einen Schlüsselexpansionsblock 75. Der Schlüsselexpansionsblock (bzw. Schlüsselerweiterungsblock) 75 erzeugt einen einzigen Rundeschlüssel, indem er in jeder Runde der AES-Blockchiffrierung eine einzelne Schlüsselexpansionsoperation durchführt.
Die Ausgangsdaten der Pufferregister 80a, 80b werden mit der XOR-Schaltung 77, 78 gekoppelt, um eine logische XOR-Operation durchzuführen. Jede XOR-Schaltung empfängt aus jedem der Pufferregister 80a, 80b den Datenblock und empfängt einen anderen Datenblock aus jedem der vier IV/OR/CTR-Register 79. Auf diese zwei Datenblöcke wird die XOR-Operation angewandt. Für jeden Systemkanal gibt es ein IV/OR/CTR-Register. Diese Register speichern den IV (Nonce) zum Berechnen von Y₀ während des Zähler-0-Standes des AES-GCM-Modus, und/oder berechnen Y_i während anderen Zuständen des Zählers (CTR) des AES-GCM-Modus. Es werden zwei andere Moden gezeigt, nämlich der ECB-Modus und der CBC-Modus. In Antwort auf ein ECB/CBC-Steuerungssignal werden Daten, die in den IV/OR/CTR-Registern 79 gespeichert sind, an die XOR-Schaltung 77, 78 übertragen, oder es wird eine aus Nullen bestehende Zeichenfolge an die XOR-Schaltung 77, 78 übertragen. In dem CBC-Modus wird auf den IV mit denen in den BIF 80a, 8ob befindlichen Daten die XOR-Funktion angewandt, bevor er an die Verschlüsselungsmodule 70a, 80b gesendet wird. In dem ECB-Modus wird ein IV nicht verwendet. In dem CTR/GCM-Modus werden die Zähler 1, 2, 3, 4 verwendet, um für eine Verschlüsselungsoperation Daten in die Verschlüsselungsmodule 70a, 70b einzugeben. Das OR (OR-Funktion) in IV/OR/CTR 1 bis 4 (bezeichnet mit 79) ist ein Ausgangsregister, welches die von den Verschlüsselungsmodulen 70a, 70b gelieferten verschlüsselten Daten speichert.
Vor jeder Runde der AES-Blockchiffrierung überträgt der Schlüsselexpansionsblock 75 den Rundenschlüssel an einen der AddRoundKey-Funktionsblöcke 74a, 74b. Es kann bis zu vier AddRoundKey-Funktionsblöcke geben (einen für jeden Datenkanal). Der Datenblock aus einem der Pufferregister 80a, 80b, auf welchen die XOR-Funktion mit dem Datenblock aus dem Register 79 angewandt wurde, wird an den AddRoundKey-Funktionsblock 74a, 74b übertragen. Der AddRoundKey-Funktionsblock 74a, 74b empfängt einen Datenblock und führt an dem Datenblock eine AddRoundKey-Transformation in Übereinstimmung mit der AES-Block-Chiffrierung aus. Der Datenblock aus dem AddRoundKey-Funktionsblock 74a, 74b wird dann an ein Eingangsregister des Chiffrierungstransformationsmoduls 70a, 70b (Chiffrierungskanal) übertragen.
Der an das Chiffrierungsblockeingangsregister der Transformationsblöcke 70a, 70b übertragene Datenblock wird dann durch die AES-Blockchiffrierungstransformationen verarbeitet, entweder zur Verschlüsselung oder Entschlüsselung. Speziell, falls die empfangenen Steuerungssignale die FSM für eines bestimmten Kanal instruieren, um Daten zu verschlüsseln, dann sind die Verschlüsselungstransformationen wirksam. Umgekehrt, falls die empfangenen Steuerungssignale die FSM für einen bestimmten Kanal instruieren, um Daten zu entschlüsseln, dann sind die Entschlüsselungstransformationen wirksam. Die Transformationsfunktionen teilen sich den kombinierten Logikschaltkreis zum Ausführen der Verschlüsselungs- oder Entschlüsselungstransformationen. Somit führt eine erste Transformation entweder die ByteSub- oder die InvByteSub- Transformation am empfangenen Datenblock aus. Gleichermaßen führen die zweite Transformation und die dritte Transformation entweder die ShiftRow- oder die InvShiftRow-Transformation bzw. die MixCol- oder die InvMixCol-Transformation aus, basierend auf das von dem bestimmten FSM-Kanal empfangenen Signal. Der Datenblock wird durch die Transformationen sukzessiv verarbeitet und dann an einen zweiten AddRoundKey-Block des Transformationsblocks 70a, 70b übertragen.
Nach dieser initialen Transformationsrunde wird der Datenblock für die nächste Transformationsrunde in die Chiffrierungsblock-Eingangsregister zurückgefüttert. Außerdem wird der Datenblock in Abhängigkeit von dem Zustand an den FIFO-Verschlüsselungszähler (ECF) 73 (einer pro Kanal) und/oder das IV/OR/CTR 79 (eines pro Kanal) übertragen.
Falls der Datenblock entschlüsselt wurde, dann wird der Datenblock über (1) die Klartextentschlüsselungsregister 68a, 68b (eines pro Kanal), (2) den Multiplexer 71, und (3) die XOR-Schaltung 72 in die Chiffrierungsblock-Eingangsregister des Transformationsmoduls 70a, 70b zurückgefüttert.
Nachdem eine vorbestimmte Anzahl von Transformationsrunden abgeschlossen wurde, wird der letzte Rundenschlüssel in dem Schlüsselexpansionsblock 75 in einem Speicher gespeichert, der sich außerhalb des AES-GCM-Engine-Moduls befindeet. Dieser letzte Rundenschlüssel ist dann zur Verwendung als der initiale Rundenschlüsselwert während einer nachfolgenden Entschlüsselungsoperation verfügbar. Der Rundenschlüsselwert wird über ein Schlüssel/CBC-Daten Multiplexregister 67, das in den/der SA-Ausgangspuffer (SAOB)-Daten/Steuerung enthalten ist, an den SA-Speicher (3) übertragen.
Die von einem der Kanal-Eingangsregister 82 an die Pufferregister 80a, 80b übertragenen Datenzeichenfolgen werden auch an die geeigneten Klartext-Speicherregister 69 übertragen. Die Datenzeichenfolgen werden in dem Klartextspeicherregister gespeichert, bis andere Datenzeichenfolgen eine vorbestimmte Anzahl von Runden lang von der Verschlüsselungs/Entschlüsselungs-Schaltung verschlüsselt (oder entschlüsselt) wurden. Die sogenannten "Klartext"-Daten in dem Klartextspeicherregister 69 werden dann an das 64-Bit-Register 65 übertragen.
Die Ausgabedatenzeichenfolgen des Ci (Chiffrierungstext) werden über den 4 × 64 Bit-Mux (Multiplexer) 66 von dem IV/OR(CTR-Register 79 (eines pro Kanal) als Ausgabedaten geliefert. Die Ausgabedatenzeichenfolgen des Ci werden als Eingabedaten verwendet, um in den GHASH-Modulen 61 (oder in der GHASH-Engine 32, gezeigt in 3) GHASH(H, A, C) auszurechnen.
Die Ausgabe des 4 × 64 Bit Mux 66 und die Ausgabe des Registers 65 werden über den Multiplexer 63 mit den GHASH-Modulen 61 (eines pro Kanal) gekoppelt. Die Ausgaben des 4 × 64 Bit Mux 65 und des Registers 65 werden über den Multiplexer 64 auch mit den 4 FIFO-Registern 62 (eines pro Kanal) gekoppelt. Der Multiplexer 63 liefert die Ci-Datenzeichenfolge oder die AAD (Klartext) an die GHASH-Module 61, um die Galois-Multiplikation (siehe 4) durchzuführen. Der Multiplexer 64 liefert über die FIFO-Register 62 den Klartext/Chiffrierungstext als eine Ausgabe. Der HASH-Schlüssel wird über die Schlüssel/CBC-Daten Mux/Register 67 zum Speichern an den SA-Speicher geliefert.
Als nächstes wird auf 7 Bezug genommen, in der eine exemplarische GHASH-Engine gezeigt ist, der insgesamt mit 90 bezeichnet wird. Es kann bis zu 4 solcher GHASH-Engines geben. Die GHASG-Engine 90 enthält eine GHASH-Steuerungseinheit 91, GHASH-Ausrichtungsmodule ("alignment modules") 95, GMULT-Module 101, GHASH-Konfigurationsmodule 103. Und GHASH-Schnittstellenmodule 107. Die GHASH-Steuerungseinheit 91 empfängt Steuerungsdaten zur Speicherung in den Steuerungsregistern 92. Die Sequenz der Zustandsmaschine wird in dem FSM-Flussmodul 93 verfolgt, während die Steuerung des GMULT-Moduls 101 mittels des Steuerungslogikmoduls 94 bereitgestellt wird.
Das GHASH-Ausrichtungsmodul 95 empfängt Datenblöcke von Chiffrierungstext (Ci), der in der AES-Engine 31 (siehe 3) berechnet wurde. An demselben Eingangsdatenbus empfängt das GHASH-Ausrichtungsmodul 95 auch die AAD-Bits (A_i). Die Datenblöcke werden über die Pipeline 96 an das Ausrichtungsmodul 97 gesendet und werden in dem Register 98 Byte-weise aktiviert ("byte enable"). Nach dem Byte-Ausrichten werden 128 Bits an das Register 100 geliefert. Falls notwendig, füllt der Multiplexer 99 einige der Bits mit Nullbits, welches von dem Auffüllmodul 102 empfangen werden.
Die Chiffrierungstext- und/oder die AAD-Bits werden an das GMULT-Modul 101 geliefert zum Durchführen einer Multiplikation des Chiffrierungstextes und/oder des AAD mit dem HASH-Schlüssel. Es können bis zu vier Hash-Schlüssel (einer pro Kanal) in dem SA-Speicher gespeichert sein. Das Steuerungslogikmodul 94 startet mit der GHASH-Multiplikation. Wie gezeigt wird, wird der Hash-Schlüssel (einer, bzw. bis zu vier Hash-Schlüssel) über das Schlüsselregister 104 an das GMUTL-Modul geliefert. Es wird verstanden werden, dass der Hash-Schlüssel schon von der AES-Engine 31 (3) berechnet wurde und in dem SA-Speicher 34 gespeichert ist. Demgemäß ist, wenn die Chiffrierungstextdaten von dem GHASH-Ausrichtungsmodul 95 empfangen werden, der Hash-Schlüssel fertig zu Verwendung durch das GMULT-Modul 101 mittels es Schlüsselregisters 104.
Das Ergebnis der Hash-Multiplikation wird an das MAC-Register 105 ausgegeben. Daher wird die GHASH(H, A, C), welche durch X_i definiert ist, unter der Steuerung durch das Adressregister 108 über den Multiplexer 106 und das Datenausgangsregister 109 ausgegeben. Die finale Berechnung des Authentifizierungstags T wird an einer anderen Steile, auf Anwendung einer XOR-Funktion auf GHASH(H, A, C) mit E(K, Y₀) (siehe 4) hin, ausgeführt.
Als nächstes wird auf 8 Bezug genommen, in der ein Verfahren zum Authentifizieren eines Datenpakets in Übereinstimmung mit einem exemplarischen Ausführungsbeispiel der Erfindung gezeigt wird. Wie gezeigt wird, liefert der Schritt 141 einen Schlüsselaustausch zwischen dem Sender und dem Empfänger. Auf diese Weise wird der Verschlüsselungsschlüssel (Chiffrierungsschlüssel) K gewonnen. Solch ein Schlüsselaustausch kann, beispielsweise, alle 100 Pakete oder bei einem von 1000 Paketen durchgeführt werden. Schritt 142 berechnet dann den GHASH-Schlüssel H unter Verwendung der AES-Engine 31 (3). Der Hash-Schlüssel H wird berechnet, indem Schlüsselexpansionen durchgeführt werden unter Verwendung von zehn Expansions-Runden für den Chiffrierungsschlüssel K (10 Taktzyklen) für einen 128-Bit-Chiffrierungsschlüssel, oder von 12 Runden (12 Taktzyklen) für einen 192-Bit-Chiffrierungsschlüssel, oder 14 Runden (14 Taktzyklen) für einen 256-Bit-Chiffrierungsschlüssel. Der Schritt 143 speichert den empfangenen Chiffrierungsschlüssel K und den berechneten Hash-Schlüssel H in dem SA-Speicher 34 (3).
Nachdem der Chiffrierungsschlüssel K und der Hash-Schlüssel H in dem SA-Speicher gespeichert wurden, verwendet Schritt 144 eine Logiksteuerungseinheit, um die Paketflusseingabe in der AES-Engine 31 zu aktivieren. Schritt 145 führt die Verschlüsselung unter Verwendung des AES-CTR-Operationsmodus durch. Schließlich authentifiziert Schritt 146 das Paket über die GHASH-Engine 32 (3) unter Verwendung des Galois-Multiplikators.
In 9 wird auf ähnliche Weise ein Verfahren zum Authentifizieren eines verschlüsselten Datenpakets auf der Empfängerseite gezeigt, in Übereinstimmung mit einem exemplarischen Ausführungsbeispiel der Erfindung. Wie gezeigt wird, liefert Schritt 151 einen Schlüsselaustausch zwischen dem Sender und dem Empfänger. Auf diese Weise wird der Entschlüsselungsschlüssel (Chriffrierungsschlüssel) K gewonnen. Solch ein Schlüsselaustausch kann, beispielsweise, alle 100 Pakete oder bei einem von 1000 Paketen durchgeführt werden. Schritt 152 berechnet dann den GHASH-Schlüssel H unter Verwendung der AES-Engine 31 (3). Der Hash-Schlüssel H wird berechnet, indem Schlüsselexpansionen durchgeführt werden unter Verwendung von zehn Expansions-Runden für den Chiffrierungsschlüssel K (10 Taktzyklen) für einen 128-Bit-Chiffrierungsschlüssel, oder von 12 Runden (12 Taktzyklen) für einen 192-Bit-Chiffrierungsschlüssel, oder 14 Runden (14 Taktzyklen) für einen 256-Bit-Chiffrierungsschlüssel. Der Schritt 153 speichert den empfangenen Chiffrierungsschlüssel K und den berechneten Hash-Schlüssel H in dem SA-Speicher 34 (3).
Nachdem der Chiffrierungsschlüssel K und der Hash-Schlüssel H in dem SA-Speicher gespeichert wurden, verwendet Schritt 154 eine Logiksteuerungseinheit, um die Paketflusseingabe in der AES-Engine 31 zu aktivieren. Schritt 155 führt die Entschlüsselung unter Verwendung des AES-CTR-Operationsmodus durch. Schließlich authentifiziert Schritt 146 das Paket über die GHASH-Engine 32 (3) unter Verwendung des Galois-Multiplikators.
Obgleich die Erfindung hierin unter Bezugnahme auf spezifische Ausführungsbeispiele gezeigt und beschrieben wurde, ist es nicht vorgesehen, die Erfindung auf die gezeigten Einzelheiten zu beschränken. Stattdessen können, innerhalb des Rahmens und der Reichweite der Äquivalente der Ansprüche und ohne von der Erfindung abzuweichen, verschiedene Modifizierungen in den Einzelheiten vorgenommen werden.

Übersetzung der in 6, Kasten 70a, 70b, 74a, 74b genannten Programmnamen:

AddRoundKey:	FügeRundenSchlüsselHinzu
MixCol:	MischeSpalten
InvMixCol:	UmkehrungMischeSpalten
ShiftRow:	SchiebeZeile
InvShiftRow:	UmkehrungSchiebeZeile
ByteSub:	ByteSubstitution
InvByteSub:	UmkehrungByteSubstitution

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

- http://csrc.nist.gov/publications/ [0008]
- csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf [0009]

Claims

Ein Authentifizierungsverschlüsselungsverfahren, aufweisend die Schritte: (a) Empfangen eines Chiffrierungsschlüssels mittels einer Fortgeschrittenen-Verschlüsselungs-Standard (AES)-Engine; (b) Berechnen, mittels der AES-Engine, eines Hash-Schlüssels unter Verwendung des empfangenen Chiffrierungsschlüssels; (c) Speichern des berechneten Hash-Schlüssels in einem Speicher; (d) Empfangen eines Datenpakets mittels der AES-Engine; (e) Verschlüsseln, mittels der AES-Engine, des Datenpaktes unter Verwendung des empfangenen Chiffrierungsschlüssels; (f) Empfangen, mittels einer GHASH-Engine, des Hash-Schlüssels aus dem Speicher; und (g) Authentifizieren des Datenpakets mittels der GHASH-Engine unter Verwendung des Hash-Schlüssels.
Verfahren gemäß Anspruch 1, wobei der Verschlüsselungsschritt Verwenden eines Zählermodus in der AES-Engine, um das Datenpaket zu verschlüsseln, enthält.
Verfahren gemäß Anspruch 2, wobei das Verwenden des Zählermodus aufweist iteratives Anwenden einer XOR-Funktion auf (a) einen Klartextbereich des Datenpakets mit (b) einem verschlüsselten Wert von Zählerdaten unter Verwendung des Chiffrierungsschlüssels und dadurch Gewinnen eines Daten-Chiffrierungstextes.
Verfahren gemäß Anspruch 1, wobei der Authentifizierungsschritt Übertragen des Chiffrierungstextes an die GHASH-Engine, und iteratives Multiplizieren des Chiffrierungstextes mittels der GHASH-Engine unter Verwendung des Hash-Schlüssels enthält.
Verfahren gemäß Anspruch 1, wobei das Verschlüsseln des Datenpakets durchgeführt wird, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde.
Verfahren gemäß Anspruch 1, ferner aufweisend den Schritt des Ermöglichens des Flusses des Datenpakets, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde.
Verfahren gemäß Anspruch 6, wobei nach dem Ermöglichen des Flusses des Datenpakets das Datenpaket unter Verwendung des Verschlüsselungsschlüssels mittels der AES-Engine verschlüsselt wird, und nach dem Ermöglichen des Flusses des Datenpakets das Datenpaket unter Verwendung des in dem Speicher gespeicherten Hash-Schlüssels mittels der GHASH-Engine authentifiziert wird.
Verfahren gemäß Anspruch 1, wobei das Berechnen des Hash-Schlüssels Durchführen von 10 Runden von Schlüssel-Erweiterungen des empfangenen Chiffrierungsschlüssel enthält, falls der empfangene Chiffrierungsschlüssel ein 128-Bit-Datenblock ist, und das Berechnen des Hash-Schlüssels Durchführen von 12 Runden von Schlüssel-Erweiterungen des empfangenen Chiffrierungsschlüssels enthält, falls der empfangene Chiffrierungsschlüssel ein 192-Bit-Datenblock ist, und das Berechnen des Hash-Schlüssels Durchführen von 14 Runden von Schlüssel-Erweiterungen empfangenen Chiffrierungsschlüssels enthält, falls der empfangene Chiffrierungsschlüssel ein 256 Bit-Datenblock ist.
Verfahren gemäß Anspruch 1, wobei das Empfangen des Chiffrierungsschlüssels Empfangen von mindestens zwei separaten Chiffrierungsschlüsseln aus entsprechenden Datenkanälen enthält, und das Berechnen des Hash-Schlüssels Berechnen von mindestens zwei separaten Hash-Schlüsseln, die mit den mindestens zwei separat empfangenen Chiffrierungsschlüsseln korrespondieren, enthält.
Verfahren gemäß Anspruchs 1, wobei das Empfangen des Datenpakets Empfangen einer vorbestimmten Anzahl von Datenpaketen während eines Zeitintervalls enthält, das Berechnen des Hash-Schlüssels Berechnen des Schlüssels einmal in dem Zeitintervall enthält, und das Speichern des Berechneten Hash-Schlüssels Speichern des Berechneten Hash-Schlüssels einmal in dem Zeitintervall enthält.
Ein Authentifizierungsentschlüsselungsverfahren, aufweisend die Schritte: (a) Empfangen eines Chiffrierungsschlüssels mittels einer Fortgeschrittenen-Verschlüsselungs-Standard (AES)-Engine; (b) Berechnen, mittels der AES-Engine, eines Hash-Schlüssels unter Verwendung des empfangenen Chiffrierungsschlüssels; (c) Speichern des berechneten Hash-Schlüssels in einem Speicher; (d) Empfangen eines Datenpakets mittels der AES-Engine; (e) Entschlüsseln, mittels der AES-Engine, des Datenpaktes unter Verwendung des empfangenen Chiffrierungsschlüssels; (f) Empfangen des Hash-Schlüssels aus dem Speicher mittels einer GHASH-Engine; und (g) Authentifizieren des Datenpakets mittels der GHASH-Engine unter Verwendung des Hash-Schlüssels.
Verfahren gemäß Anspruch 11, wobei der Verschlüsselungsschritt, um das Datenpaket zu verschlüsseln, Verwenden eines Zählermodus in dem AES-Engine enthält.
Verfahren gemäß Anspruch 11, wobei das Entschlüsseln des Datenpakets durchgeführt wird, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde.
Verfahren gemäß Anspruch 11, ferner aufweisend den Schritt des Ermöglichens des Flusses des Datenpakets, nachdem der Hash-Schlüssel in dem Speicher gespeichert wurde.
Verfahren gemäß Anspruch 14, wobei nach dem Ermöglichen des Flusses des Datenpakets das Datenpaket unter Verwendung des Verschlüsselungsschlüssels mittels der AES-Engine entschlüsselt wird, und nach dem Ermöglichen des Flusses des Datenpakets das Datenpaket unter Verwendung des in dem Speicher gespeicherten Hash-Schlüssels mittels der GHASH-Engine authentifiziert wird.
Ein Authentifizierungsverschlüsselungsmodul, aufweisend: eine Fortgeschrittenen-Verschlüsselungs-Standard (AES)-Engine zum Verwenden eines Chiffrierungsschlüssels, um einen Hash-Schlüssel zu berechnen, einen Speicher zum Speichern des berechneten Hash-Schlüssels, und eine GHASH-Engine zum Empfangen des berechneten Hash-Schlüssels, der in dem Speicher gespeichert wurde, zum Authentifizieren eines Datenpakets, wobei (a) die AES-Engine das Datenpaket verschlüsselt, um einen Chiffrierungstext zu erzeugen, (b) die GHASH-Engine den Chiffrierungstext aus dem AES-Engine empfängt, um den empfangenen Chiffrierungstext mit dem berechneten Hash-Schlüssel zu multiplizieren, und (c) ein Authentifizierungstag unter Verwendung des mit dem berechneten Hash-Schlüssels multiplizierten Chiffrierungstextes berechnet wird.
Modul gemäß Anspruch 16, das eine Steuerungseinheit zum Freigeben des Eingangsflusses des Datenpakets, nachdem der berechnete Hash-Schlüssel in dem Speicher gespeichert wurde enthält.
Modul gemäß Anspruch 16, wobei das Datenpaket zusätzliche Authentifizierungsdaten (AAD) enthält, und die GHASH-Engine dazu gestaltet ist, die AAD zu empfangen, um die AAD mit dem berechneten Hash-Schlüssel zu multiplizieren.
Modul gemäß Anspruch 16, wobei die AES-Engine dazu gestaltet ist, mindestens zwei unterschiedliche Verschlüsselungsschlüssel aus entsprechenden Datenkanälen zu empfangen, und die AES-Engine zwei Verschlüsselungsmodule zum Verschlüsseln von mindestens zwei unterschiedlichen Datenpaketen, die unter Verwendung der mindestens zwei unterschiedlichen Verschlüsselungsschlüssel aus den entsprechenden Datenkanälen empfangenen wurden, enthält.
Modul gemäß Anspruch 16, wobei das Datenpaket mehrere Datenpakete enthält, und der Hash-Schlüssel einmal berechnet wird für alle von den mehreren empfangenen Datenpaketen, und der Hash-Schlüssel einmal gespeichert wird für alle von den mehreren empfangenen Datenpaketen.