Mein Team muss eine Lösung entwickeln, um binäre Daten (gespeichert als byte[] ) im Kontext einer in Java geschriebenen Android-Anwendung zu verschlüsseln. Die verschlüsselten Daten werden auf verschiedene Arten übertragen und gespeichert, wobei eine Datenkorruption nicht ausgeschlossen werden kann. Schließlich muss eine andere Android-Anwendung (wieder in Java geschrieben) die Daten entschlüsseln.
Es wurde bereits entschieden, dass der Verschlüsselungsalgorithmus AES mit einem Schlüssel von 256 Bits sein muss. Ich möchte jedoch eine fundierte Entscheidung darüber treffen, welche AES-Implementierung und / oder "Modus" wir verwenden sollten. Ich habe etwas gelesen, das GCM-Modus heißt, und wir haben einige Tests mit ihm gemacht (mit BouncyCastle / SpongyCastle), aber mir ist nicht ganz klar, wofür genau AES-GCM ist und was es uns im Vergleich zu einfach "kauft" AES - und ob es Kompromisse gibt.
Hier ist eine Liste von Bedenken / Anforderungen / Fragen, die wir haben:
Padding: Die Daten, die wir verschlüsseln müssen, sind nicht immer ein Vielfaches der 128 Bits. Daher sollte die AES-Implementierung / Modus Padding hinzufügen, jedoch nur bei Bedarf.
Ich hatte den Eindruck, dass eine einfache AES-Implementierung, wie sie von javax.crypto.Cipher bereitgestellt wird, dies nicht tun würde, aber erste Tests haben ergeben, dass dies der Fall ist. Ich vermute also, dass die Polsterungsanforderung an sich kein Grund ist, auf etwas wie GCM statt auf "einfaches" AES zurückzugreifen. Stimmt das?
Authentifizierung: Wir brauchen eine narrensichere Methode, um festzustellen, ob Daten beschädigt sind. Idealerweise möchten wir aber auch erkennen, wenn die Entschlüsselung mit einem falschen Schlüssel versucht wird. Daher wollen wir in der Lage sein, zwischen diesen beiden Fällen zu unterscheiden. Der Grund, warum ich am Ende GCM in Betracht gezogen habe, lag an dieser Stackoverflow-Frage , wo einer der Responder anscheinend andeutet Diese Unterscheidung ist mit AES-GCM möglich, obwohl er keine detaillierte Erklärung (geschweige denn Code) liefert.
Aufwand minimieren: Wir müssen den Aufwand für die Speicherung und Übertragung der verschlüsselten Daten begrenzen. Daher möchten wir wissen, ob und in welchem Umfang die Wahl einer bestimmten AES-Implementierung / -Modus die Höhe der Gemeinkosten beeinflusst.
Verschlüsselungs- / Entschlüsselungsleistung: Obwohl es kein primäres Problem ist, fragen wir uns, in welchem Ausmaß die Wahl einer bestimmten AES-Implementierung / Modus die Verschlüsselungs- und Entschlüsselungsleistung beeinflusst, sowohl in Bezug auf CPU-Zeit und Speicherbedarf.
Vielen Dank im Voraus für Ratschläge, Erläuterungen und / oder Codebeispiele.
BEARBEITEN: delnan hat hilfreicherweise darauf hingewiesen, dass es so etwas wie "plain AES" nicht gibt. Um zu verdeutlichen, was ich damit meine, verwende ich Javas integrierte AES-Unterstützung.
Wie folgt: Cipher localCipher = Cipher.getInstance("AES");
Im Jahr 2012 lautet die Antwort GCM, es sei denn, Sie haben ernsthafte Kompatibilitätsprobleme.
GCM ist ein authentifizierter Verschlüsselungsmodus . Es bietet Ihnen Vertraulichkeit (Verschlüsselung), Integrität und Authentifizierung (MAC) auf einmal.
Bisher waren die normalen Betriebsmodi ECB (das ist die Standardeinstellung für Java ), CBC, CTR, OFB und ein paar andere. Sie alle lieferten nur Verschlüsselung. Vertraulichkeit allein ist selten ohne Integrität nützlich; man musste solche klassischen Modi mit Integritätsprüfungen ad hoc kombinieren. Da Kryptographie schwer zu bekommen ist, waren solche Kombinationen oft unsicher, langsamer als nötig oder sogar beides.
Authentifizierte Verschlüsselung Modi wurden (vor kurzem) von Kryptografen entwickelt, um dieses Problem zu lösen. GCM ist eines der erfolgreichsten: Es wurde von NIST ausgewählt Es ist effizient, es ist patentfrei und es kann zusätzliche authentifizierte Daten (dh Daten, die im Klartext bleiben, aber für die Sie die Authentizität verifizieren können) enthalten. Für eine Beschreibung anderer Modi siehe diesen ausgezeichneten Artikel von Matthew Green .
Kommen Sie zu Ihren Bedenken:
Padding: Java verwendet standardmäßig PKCS # 7 Padding. Das funktioniert, aber es ist oft anfällig für Padding-Orakel-Angriffe , die am besten mit einem MAC . GCM bettet bereits einen MAC (genannt GMAC) ein.
Authentifizierung: AES-GCM verwendet nur einen AES-Schlüssel als Eingabe und keine Kennwörter. Es wird Ihnen sagen, ob der AES-Schlüssel falsch ist oder die Nutzlast manipuliert wurde, aber solche Bedingungen werden als eine behandelt. Stattdessen sollten Sie einen geeigneten Schlüsselableitungsalgorithmus wie PBKDF2 oder bcrypt , um den AES-Schlüssel aus dem Passwort abzuleiten. Ich glaube nicht, dass es immer möglich ist, zu sagen, ob das Passwort falsch ist oder ob die Nutzdaten geändert wurden, weil die Daten, die notwendig sind, um das Erstere zu verifizieren, immer verfälscht sein können. Sie können eine kleine bekannte Zeichenfolge (mit ECB AES) verschlüsseln, mitschicken und verwenden, um zu überprüfen, ob das Passwort korrekt ist.
Aufwand minimieren: Am Ende des Tages führen alle Modi zu demselben Overhead (ca. 10-20 Byte), wenn Sie eine Authentifizierung wünschen. Sofern Sie nicht mit sehr kleinen Nutzlasten arbeiten, kann dieser Punkt ignoriert werden.
Leistung: GCM ist ziemlich gut, da es ein online Modus ist (keine Notwendigkeit, die gesamte Nutzlast zu puffern, also weniger Speicher), es ist parallelisierbar , und es erfordert eine AES-Operation und eine Galois-Multiplikation pro Klartextblock. Klassische Modi wie ECB sind schneller (nur eine AES-Operation pro Block), aber - wieder - müssen Sie auch die Integritätslogik berücksichtigen, die möglicherweise langsamer als GMAC ist.
Nachdem dies gesagt wurde, muss man sich darüber im Klaren sein, dass die GCM-Sicherheit auf einer guten Zufallszahlengenerierung für die Erstellung der IV beruht.
Tags und Links android encryption bouncycastle aes aes-gcm