Aws-cli: aws kms decrypt InvalidCiphertextException-Fehler

Nur ein paar Hintergrundinfos zum aktuellen Geschehen:

In 1.6.6 haben wir eine Regression behoben , bei der wir "Blob"-Typen nicht base64

$ aws kms encrypt --key-id <key-id> --plaintext "abcd" --query CiphertextBlob --output text | base64 -D > /tmp/encrypted-file
$ echo "Decrypted: $(aws kms decrypt --ciphertext-blob fileb:///tmp/encrypted-file --query Plaintext --output text | base64 -D)"
Decrypted: abcd

In diesem Beispiel verwende ich auch das Präfix fileb:// da es sich um eine Datei mit binärem Inhalt handelt.

Ich finde, das Verhalten sollte so bleiben, wie es ist. Da das Verhalten in dieser ersten Ausgabe auf einer Regression in 1.6.5 beruhte, die in 1.6.6 behoben wurde, können wir das bereits vorhandene Verhalten wirklich nicht ändern, da dies eine bahnbrechende Änderung für die Kunden wäre. Das obige Beispiel-Snippet ist die erwartete Art und Weise, wie die binäre Eingabe/Ausgabe in der AWS CLI behandelt wird, und abgesehen von dieser kürzlichen Regression war dieses Verhalten schon immer so.

Danke für das Update!

Tatsächlich erhalte ich jetzt einen ähnlichen Fehler wie bei Ausgabe Nr. 1001

$> aws kms encrypt --key-id $KMS_KEY_ID --plaintext "abcd" --query CiphertextBlob --output text | base64 -D > /tmp/encrypted-file

$> echo "Decrypted: $(aws kms decrypt --ciphertext-blob fileb:///tmp/encrypted-file --query Plaintext --output text | base64 -D)"

'ascii' codec can't decode byte 0xdd in position 2: ordinal not in range(128)
Decrypted: 

@mtougeron Welche Version der AWS CLI verwenden Sie? Ich habe es gerade erneut mit der neuesten Version der AWS CLI (1.6.8) versucht und dieses Problem sehe ich nicht:

~ $ aws kms encrypt --key-id $AWS_KEY_ID --plaintext "abcd" --query CiphertextBlob --output text | base64 -D > /tmp/encrypted-file
~ $ hexdump -C /tmp/encrypted-file
00000000  0a 20 e1 68 92 dc 42 40  fe 07 80 ca f6 54 1c 68  |. [email protected]|
00000010  e2 45 80 bb c3 e0 2a 2f  91 50 7c ac c3 02 9b c9  |.E....*/.P|.....|
00000020  a8 b3 12 8b 01 01 01 02  00 78 e1 68 92 dc 42 40  |.........x.h..B@|
00000030  fe 07 80 ca f6 54 1c 68  e2 45 80 bb c3 e0 2a 2f  |.....T.h.E....*/|
00000040  91 50 7c ac c3 02 9b c9  a8 b3 00 00 00 62 30 60  |.P|..........b0`|
00000050  06 09 2a 86 48 86 f7 0d  01 07 06 a0 53 30 51 02  |..*.H.......S0Q.|
00000060  01 00 30 4c 06 09 2a 86  48 86 f7 0d 01 07 01 30  |..0L..*.H......0|
00000070  1e 06 09 60 86 48 01 65  03 04 01 2e 30 11 04 0c  |...`.H.e....0...|
00000080  41 de f2 2a a6 c5 38 ef  8a 52 54 92 02 01 10 80  |A..*..8..RT.....|
00000090  1f 2e 01 90 65 7a 21 8c  dd 05 e4 4d 09 64 85 c4  |....ez!....M.d..|
000000a0  33 e3 3d e9 ce 33 6b e9  00 93 ec e5 54 33 8b 3b  |3.=..3k.....T3.;|
000000b0
~ $ echo "Decrypted: $(aws kms decrypt --ciphertext-blob fileb:///tmp/encrypted-file --query Plaintext --output text | base64 -D)"
Decrypted: abcd
~ $ aws --version
aws-cli/1.6.8 Python/2.7.7 Darwin/13.4.0

@jamesls es funktioniert jetzt in 1.6.8. Danke

@jamesls persönlich denke ich, dass dies eine unglaublich schlechte Benutzeroberfläche ist. Sie können nicht denselben Chiffretext an die Entschlüsselung übergeben, den Sie von encrypt erhalten haben? Wenn Sie es nicht ändern können, weil Sie bestehende Kunden nicht brechen möchten, geben Sie ihnen zumindest eine bessere Fehlermeldung.

A client error (InvalidCiphertextException) occurred when calling the Decrypt operation: None

Sagt mir nicht einmal aus der Ferne, was zu tun ist, um das Problem zu beheben. Sie könnten feststellen, dass die Chiffre wahrscheinlich Base64 ist und einen besseren Fehler ausgeben und sie auf eine URL oder so verweisen.

Oder warum nicht ein zusätzliches Flag an decrypt zu sagen, "dass zuerst von base64 dekodiert"?

Für diejenigen, die später dazu kommen, können Sie Folgendes tun, _ohne_ den Geheimtext in einer Datei zu speichern:

aws kms decrypt --ciphertext-blob fileb://<(echo 'ciphertext' | base64 -d)

Hinweis: Wie von @hauntingEcho unten erwähnt, ist <(cmd) nicht POSIX-kompatibel. Wenn Sie also sh , funktioniert es nicht, aber bash und zsh funktioniert einwandfrei.

Betreff : Kommentar von @thegranddesign , unter OS X musste ich zumindest ein base64 . Z.B:

$ echo "Decrypted: $(aws kms decrypt --ciphertext-blob fileb://<(echo $ENCRYPTED_DATA | base64 -D) --query Plaintext --output text | base64 -D)"

Decrypted: Hello world!

(Ich bin mir nicht sicher, warum ich einen Zeilenumbruch vor der Zeile Decrypted bekomme, aber keine große Sache).

Das hat bei mir funktioniert

#encrypt the password: TestReadWrite text in the test.txt file
aws kms encrypt --key-id cfc7acf7-4f20-49c3-aa11-8be4cdc3291d --plaintext fileb://test.txt --output text | base64 --decode > out.txt

#decrypt the password: TestReadWrite
aws kms decrypt  --ciphertext-blob fileb://out.txt --output text --query Plaintext | base64 --decode

Ich hatte ein ähnliches Problem, aber Node hat geholfen:

'use strict';

const KMS = require('aws-sdk').KMS;
const fs = require('fs');

const kms = new KMS({
  apiVersion: '2014-11-01',
  // region: 'eu-west-1'
});

function encrypt(params) {
  return kms.encrypt(params).promise();
}

const arn = 'arn:aws:kms:xxx';

encrypt({
  KeyId: arn,
  Plaintext: fs.readFileSync('/path/to/key.pem')
})
.then(data => fs.writeFileSync('/path/to/key.json', JSON.stringify(data)));

ein weiterer Hinweis zur Lösung von @thegranddesign - <(cmd) ist ein Bashism, nicht POSIX-kompatibel, daher müssen Sie eine andere Lösung verwenden, wenn Bash keine Option ist.

Dies ist ein unglaublich dummer Fehler, der wirklich noch offen sein sollte, bis er tatsächlich behoben ist. Es ist ein riesiges Anti-Muster, ein Werkzeug zu bauen, das eine symmetrische Operation durchführt, die ein Format für die Ausgabe und ein völlig anderes (und inkompatibles) Format für die Eingabe verwendet. Ein symmetrisches Werkzeug, das seine eigene Ausgabe nicht als Eingabe verbrauchen kann, ist BROKEN. Es ist mir egal, ob es tatsächlich wie vorgesehen funktioniert, es ist immer noch kaputt. Das Tool sollte entweder standardmäßig eine rohe Binärausgabe generieren, wenn es von einer rohen binären Eingabe abhängig ist, oder es sollte verdammt gut in der Lage sein, base64-codierte Eingaben zu konsumieren, die es ERZEUGT hat, ohne explizite base64-Dekodierungsschritte oder spezielle Parameter anzugeben, die nicht angegeben wurden auch erforderlich, um diese Ausgabe zu generieren (oder einen Anti-Parameter, wenn er nicht genau denselben Parameter verwendet). Es ist mehr als absurd, dass ich aws kms encrypt verwenden kann, um eine base64-kodierte Ausgabe einer base64-kodierten Verschlüsselungsnutzlast zu generieren, ohne EINE dieser base64-Kodierungen anzugeben, aber dann muss ich explizit sowohl die verschlüsselten Daten als auch die entschlüsselten Daten dekodieren, um zu erhalten es zurück zu dem Formular, das ich an erster Stelle bereitgestellt habe. Die Tatsache, dass dies auch die Verwendung von Befehlszeilenparametern erfordert, die nicht einmal auf der Ebene der Unterbefehle encrypt und decrypt dokumentiert sind, macht es viel schwieriger, dies herauszufinden. Benutzer werden fast garantiert Stunden damit verschwenden, herauszufinden, wie man die offensichtlichste Sache macht, die jemand mit einem Verschlüsselungs-/Entschlüsselungs-Client machen möchte - eine in einem Befehlszeilenparameter angegebene Zeichenfolge verschlüsseln und dann entschlüsseln - und das ausschließlich, weil das Tool hat einen defekten Betriebsmodus, bei dem die Ausgänge nicht mit den Eingängen kompatibel sind, obwohl die beiden Unterbefehle symmetrisch sein sollen. Wenn Sie dies schließen, ohne es zu beheben, haben Sie keinerlei Bedenken hinsichtlich der Benutzerfreundlichkeit oder der Entwicklereffizienz.

Ein anderer Weg, dies zu beheben (im Gegensatz zu neuen Flags, wie @thegranddesign vor Jahren erwähnte) könnte darin bestehen, dass / kein gültiges base64-Zeichen ist und es keine gültige Möglichkeit gibt, Binärdaten in json anzugeben. Deswegen:

• Wenn der Parameter ciphertext-blob gültig base-64 ist, übergeben Sie ihn als base 64
• Wenn der Parameter ciphertext-blob / , wird als Pfad geparst. fileb:// tut sein aktuelles Verhalten, file:// könnte b64-kodiert sein.

Ich stimme @sgendler-stem jedoch zu - dieses Ticket ist in jedem Projekt verlinkt, an dem ich gearbeitet habe, das KMS verwendet, weil es immer ein Problem für jemanden ist, der versucht, an Bord zu kommen.

Dies ist ein unglaublich dummer Fehler, der wirklich noch offen sein sollte, bis er tatsächlich behoben ist. Es ist ein riesiges Anti-Muster, ein Werkzeug zu bauen, das eine symmetrische Operation durchführt, die ein Format für die Ausgabe und ein völlig anderes (und inkompatibles) Format für die Eingabe verwendet. Ein symmetrisches Werkzeug, das seine eigene Ausgabe nicht als Eingabe verbrauchen kann, ist BROKEN. Es ist mir egal, ob es tatsächlich wie vorgesehen funktioniert, es ist immer noch kaputt. Das Tool sollte entweder standardmäßig eine rohe Binärausgabe generieren, wenn es von einer rohen binären Eingabe abhängig ist, oder es sollte verdammt gut in der Lage sein, base64-codierte Eingaben zu konsumieren, die es ERZEUGT hat, ohne explizite base64-Dekodierungsschritte oder spezielle Parameter anzugeben, die nicht angegeben wurden auch erforderlich, um diese Ausgabe zu generieren (oder einen Anti-Parameter, wenn er nicht genau denselben Parameter verwendet). Es ist mehr als absurd, dass ich aws kms encrypt verwenden kann, um eine base64-kodierte Ausgabe einer base64-kodierten Verschlüsselungsnutzlast zu generieren, ohne EINE dieser base64-Kodierungen anzugeben, aber dann muss ich explizit sowohl die verschlüsselten Daten als auch die entschlüsselten Daten dekodieren, um zu erhalten es zurück zu dem Formular, das ich an erster Stelle bereitgestellt habe. Die Tatsache, dass dies auch die Verwendung von Befehlszeilenparametern erfordert, die nicht einmal auf der Ebene der Unterbefehle encrypt und decrypt dokumentiert sind, macht es viel schwieriger, dies herauszufinden. Benutzer werden fast garantiert Stunden damit verschwenden, herauszufinden, wie man die offensichtlichste Sache macht, die jemand mit einem Verschlüsselungs-/Entschlüsselungs-Client machen möchte - eine in einem Befehlszeilenparameter angegebene Zeichenfolge verschlüsseln und dann entschlüsseln - und das ausschließlich, weil das Tool hat einen defekten Betriebsmodus, bei dem die Ausgänge nicht mit den Eingängen kompatibel sind, obwohl die beiden Unterbefehle symmetrisch sein sollen. Wenn Sie dies schließen, ohne es zu beheben, haben Sie keinerlei Bedenken hinsichtlich der Benutzerfreundlichkeit oder der Entwicklereffizienz.

Ich muss @sgendler-stem voll und ganz zustimmen - wenn der Code eine Ausgabe generiert, sollte er diese zumindest als Eingabe annehmen können.

Dazu gehört jedoch noch mehr. Wenn die Verschlüsselung über das SDK erfolgt und ein seltsames arn am Ende der verschlüsselten Datei hinzugefügt wird, kann die CLI sie nicht entschlüsseln, selbst nachdem das Nicht-Base64- arn URL. Das ist einfach kaputt .

Wieder zugestimmt. Dies hat die Dinge unnötig frustrierend gemacht.

Ist das eigentlich geschlossen? Wieso den? Ich kann nicht glauben, dass es 4 Jahre her ist, seit dies eröffnet wurde und das einzige Feedback scheint jemand zu sein, der sagt "funktioniert wie beabsichtigt". Nein, das tut es verdammt noch mal nicht; @sgendler-stem ist genau richtig, das ist komplett kaputt. Ich hoffe, das verantwortliche Team fühlt sich schlecht.

Es gelten die gleichen Ausnahmen:
botocore.errorfactory.InvalidCiphertextException: Beim Aufrufen des Decrypt-Vorgangs ist ein Fehler aufgetreten (InvalidCiphertextException):

Gebraucht:
Schlüssel = b64decode (Schlüssel)
antwort = client.decrypt(
CiphertextBlob=Schlüssel
)

Ich denke, das wäre nicht so frustrierend, wenn die Ausgabe von encrypt , generate-data-key usw. nicht das Feld CiphertextBlob aufrufen würde. Wenn die Eingabe für decrypt auch --ciphertext-blob heißt, ist es völlig unintuitiv, dass dieser Geheimtext-Blob anders codiert werden muss.

Wenn das Flag für decrypt einen anderen Namen hätte, wäre dies ein Hinweis darauf, dass es eine andere Codierung hat.

Es gibt einen Funktionsvorschlag für base64-codierte Eingaben zum Entschlüsseln hier https://github.com/aws/aws-cli/issues/2063

@ojitha

Woher weiß kms, welcher Verschlüsselungsschlüssel für die Entschlüsselung verwendet werden soll, da wir beim Entschlüsseln keine Schlüssel-ID als Parameter übergeben.

@arpit728 Ich denke, dass CipherTextBlob zurückgegeben wird, ist speziell auf die KeyID eines bestimmten CMK zurückzuführen.

Bitte öffnen Sie dieses Ticket erneut, bis es gelöst ist!

habe zu viele Stunden damit gespielt, bis ich dieses Ticket gefunden habe. Gibt es eine offizielle Dokumentation, in der angegeben ist, wie genau Dinge codiert und zwischen Verschlüsseln und Entschlüsseln umgewandelt werden sollten?

Nur ein paar Hintergrundinfos zum aktuellen Geschehen:

In 1.6.6 haben wir eine Regression behoben , bei der wir "Blob"-Typen nicht base64

$ aws kms encrypt --key-id <key-id> --plaintext "abcd" --query CiphertextBlob --output text | base64 -D > /tmp/encrypted-file
$ echo "Decrypted: $(aws kms decrypt --ciphertext-blob fileb:///tmp/encrypted-file --query Plaintext --output text | base64 -D)"
Decrypted: abcd

In diesem Beispiel verwende ich auch das Präfix fileb:// da es sich um eine Datei mit binärem Inhalt handelt.

dieses Beispiel gibt zurück:

Beim Aufrufen des Vorgangs Entschlüsseln ist ein Fehler aufgetreten (InvalidCiphertextException):
Entschlüsselt:

`aws kms encrypt --key-id arn:aws:kms:eu-west-1werwerwjl:key/xxxyyyy --plaintext "abcd" --query CiphertextBlob --output text | base64 -d > ./encrypted-file

echo "Entschlüsselt: $(aws kms decrypt --ciphertext-blob fileb:./encrypted-file --query Plaintext --output text | base64 --decode)"
`
Habe es mit Ubuntu versucht. Wenn jemand eine klare Dokumentation oder Beispiele (Link zu einer Site oder so) kennt, wäre ich sehr dankbar!

BEARBEITEN: Verschlüsseln und entschlüsseln funktioniert mit Tipps aus diesem Artikel: https://dev.to/matchilling/pragmatic-storing-security-sensitive-data-using-aws-kms-5e5b

Zu Ihrer Information, der obige Link funktioniert nicht, aber der Artikel scheint ziemlich nützlich zu sein und ist hier verfügbar .