Aws-cli: aws kms расшифровать ошибку InvalidCiphertextException

Небольшая справочная информация о том, что происходит:

В версии 1.6.6 мы исправили регрессию, при которой мы не кодировали типы «blob» в base64, которые кодировали ранее. В результате вам теперь нужно указать необработанные двоичные байты для любого параметра, помеченного как тип «blob», и внутренне мы автоматически закодируем его в base64. Это означает, что для шифрования ключей туда и обратно вам нужно сначала декодировать 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

В этом примере я также использую префикс fileb:// потому что это файл с двоичным содержимым.

Я считаю, что поведение должно оставаться неизменным. Учитывая, что поведение в этой начальной проблеме основывалось на регрессии в 1.6.5, которая была исправлена ​​в 1.6.6, мы действительно не можем изменить ранее существовавшее поведение, поскольку это было бы критическим изменением для клиентов. Приведенный выше фрагмент примера - это ожидаемый способ обработки двоичного ввода / вывода в AWS CLI, и, за исключением этой недавней регрессии, это поведение всегда было таким.

Спасибо за обновления!

Собственно, теперь я получаю ошибку, похожую на проблему №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 Какую версию интерфейса командной строки AWS вы используете? Я просто снова попробовал использовать последнюю версию интерфейса командной строки AWS (1.6.8), но не вижу этой проблемы:

~ $ 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 теперь работает в 1.6.8. Благодарность

@jamesls лично я считаю, что это невероятно плохой интерфейс. Не можете передать тот же зашифрованный текст для дешифрования, который вы получили от encrypt? Если вы не можете его изменить, потому что не хотите разрушать существующих клиентов, по крайней мере, дайте им более четкое сообщение об ошибке.

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

Даже отдаленно не говорит мне, что делать, чтобы решить проблему. Вы можете обнаружить, что шифр, вероятно, является Base64, и вывести лучшую ошибку и указать им URL-адрес или что-то в этом роде.

Или, черт возьми, почему бы не передать дополнительный флаг decrypt чтобы сказать «сначала декодируйте это из base64»?

Для тех, кто придет к этому позже, чтобы сделать это _без_ сохранения зашифрованного текста в файл, вы можете сделать:

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

Примечание: как указано ниже @hauntingEcho , <(cmd) не совместим с POSIX, поэтому, если вы используете sh , он не будет работать, но bash и zsh работают нормально.

Re: комментарий @thegranddesign , по крайней мере, в OS X мне пришлось использовать заглавную base64 . Например:

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

Decrypted: Hello world!

(Не уверен, почему я получаю новую строку перед строкой Decrypted , но это не имеет большого значения).

Это сработало для меня

#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

У меня была аналогичная проблема, но Node помог:

'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)));

еще одно примечание о решении @thegranddesign - <(cmd) является bashism, не совместимым с POSIX, поэтому вам нужно будет использовать другое решение, если bash не подходит.

Это ошеломляюще глупая ошибка, которая действительно должна оставаться открытой, пока она не будет исправлена. Это гигантский анти-шаблон для создания инструмента, выполняющего симметричную операцию, использующую один формат для вывода и совершенно другой (и несовместимый) формат для ввода. Симметричный инструмент, который не может использовать собственные выходные данные в качестве входных, является ПОВРЕЖДЕННЫМ. Меня не волнует, действительно ли он работает так, как задумано, он все еще сломан. Инструмент должен либо генерировать необработанный двоичный вывод по умолчанию, если он зависит от необработанного двоичного ввода, либо, черт возьми, он должен иметь возможность использовать закодированный в base64 ввод, КОТОРЫЙ ОН ГЕНЕРИРУЕТСЯ, без указания каких-либо явных шагов декодирования base64 или специальных параметров, которые не были также требуется для генерации этого вывода (или антипарама, если он не использует тот же самый точный параметр). Совершенно абсурдно то, что я могу использовать aws kms encrypt для генерации выходных данных в кодировке base64 полезной нагрузки для шифрования в кодировке base64 без указания ЛИБО из этих кодировок base64, но тогда мне нужно явно base64 декодировать как зашифрованные данные, так и расшифрованные данные, чтобы получить это обратно к форме, которую я предоставил в первую очередь. Тот факт, что для этого также требуется использование параметров командной строки, которые даже не задокументированы на уровне подкоманд encrypt и decrypt, делает это намного более трудным для понимания. Пользователи почти гарантированно тратят часы, пытаясь выяснить, как сделать самую очевидную вещь, которую кто-то может захотеть сделать с клиентом шифрования / дешифрования - зашифровать, а затем расшифровать строку, указанную в параметре командной строки, - и полностью потому, что инструмент имеет нарушенный режим работы, когда выходы несовместимы с входами, несмотря на то, что две подкоманды должны быть симметричными. Если закрыть это без исправления, это означает, что вы совершенно не заботитесь об удобстве использования или эффективности разработчика.

другой путь для решения этой проблемы (в отличие от новых флагов, как @thegranddesign упоминал много лет назад) может заключаться в том, что / не является допустимым символом base64, и нет допустимого способа указать двоичные данные в json. Следовательно:

• если параметр ciphertext-blob является допустимым base-64, передайте его как base 64
• если параметр ciphertext-blob содержит / , анализировать как путь. fileb:// выполняет свое текущее поведение, file:// может быть закодирован в b64.

Однако согласен с @ sgendler-stem - этот билет связан с каждым проектом, над которым я работал и использующим KMS, потому что это всегда проблема для тех, кто пытается попасть на борт.

Это ошеломляюще глупая ошибка, которая действительно должна оставаться открытой, пока она не будет исправлена. Это гигантский анти-шаблон для создания инструмента, выполняющего симметричную операцию, использующую один формат для вывода и совершенно другой (и несовместимый) формат для ввода. Симметричный инструмент, который не может использовать собственные выходные данные в качестве входных, является ПОВРЕЖДЕННЫМ. Меня не волнует, действительно ли он работает так, как задумано, он все еще сломан. Инструмент должен либо генерировать необработанный двоичный вывод по умолчанию, если он зависит от необработанного двоичного ввода, либо, черт возьми, он должен иметь возможность использовать закодированный в base64 ввод, КОТОРЫЙ ОН ГЕНЕРИРУЕТСЯ, без указания каких-либо явных шагов декодирования base64 или специальных параметров, которые не были также требуется для генерации этого вывода (или антипарама, если он не использует тот же самый точный параметр). Совершенно абсурдно то, что я могу использовать aws kms encrypt для генерации выходных данных в кодировке base64 полезной нагрузки для шифрования в кодировке base64 без указания ЛИБО из этих кодировок base64, но тогда мне нужно явно base64 декодировать как зашифрованные данные, так и расшифрованные данные, чтобы получить это обратно к форме, которую я предоставил в первую очередь. Тот факт, что для этого также требуется использование параметров командной строки, которые даже не задокументированы на уровне подкоманд encrypt и decrypt, делает это намного более трудным для понимания. Пользователи почти гарантированно тратят часы, пытаясь выяснить, как сделать самую очевидную вещь, которую кто-то может захотеть сделать с клиентом шифрования / дешифрования - зашифровать, а затем расшифровать строку, указанную в параметре командной строки, - и полностью потому, что инструмент имеет нарушенный режим работы, когда выходы несовместимы с входами, несмотря на то, что две подкоманды должны быть симметричными. Если закрыть это без исправления, это означает, что вы совершенно не заботитесь об удобстве использования или эффективности разработчика.

Я должен полностью согласиться с @ sgendler-stem - если код генерирует вывод, он должен, по крайней мере , принять это как ввод.

Однако это еще не все. Если шифрование выполняется через SDK - добавление странного arn в конец зашифрованного файла, CLI не сможет его расшифровать, даже после удаления не-base64 arn URL. Это просто сломано .

Снова согласился. Это сделало вещи излишне разочаровывающими.

Это действительно закрыто? Почему? Я не могу поверить, что прошло 4 года с тех пор, как это открылось, и кажется, что единственная обратная связь - кто-то говорит: «Работает, как задумано». Нет, черт возьми, нет; @ sgendler-stem попадает точно в цель, он полностью сломан. Надеюсь, что ответственная команда плохо себя чувствует.

Столкнулись с теми же исключениями:
botocore.errorfactory.InvalidCiphertextException: произошла ошибка (InvalidCiphertextException) при вызове операции дешифрования:

Использовал:
ключ = b64decode (ключ)
response = client.decrypt (
CiphertextBlob = ключ
)

Я думаю, это не было бы так неприятно, если бы в выводе encrypt , generate-data-key и т. Д. Не было вызывалось поле CiphertextBlob . Когда вход в decrypt также называется --ciphertext-blob , совершенно не интуитивно понятно, что этот большой двоичный объект зашифрованного текста должен быть закодирован по-другому.

Если бы флаг decrypt имел другое имя, это было бы намеком на то, что он имеет другую кодировку.

Здесь есть предложение по расшифровке входных данных в кодировке base64 https://github.com/aws/aws-cli/issues/2063

@ojitha

Как kms узнает, какой ключ шифрования использовать для дешифрования, поскольку мы не передаем идентификатор ключа в качестве параметра при дешифровании.

@ arpit728 Я думаю, что возвращаемый CipherTextBlob относится к KeyID конкретного CMK.

Пожалуйста, откройте этот тикет, пока он не будет разрешен!

играл слишком много часов с этим, пока не нашел этот билет. есть ли какая-либо официальная документация, в которой указано, как именно нужно кодировать и преобразовывать между шифрованием и дешифрованием?

Небольшая справочная информация о том, что происходит:

В версии 1.6.6 мы исправили регрессию, при которой мы не кодировали типы «blob» в base64, которые кодировали ранее. В результате вам теперь нужно указать необработанные двоичные байты для любого параметра, помеченного как тип «blob», и внутренне мы автоматически закодируем его в base64. Это означает, что для шифрования ключей туда и обратно вам нужно сначала декодировать 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

В этом примере я также использую префикс fileb:// потому что это файл с двоичным содержимым.

этот пример возвращает:

Произошла ошибка (InvalidCiphertextException) при вызове операции расшифровки:
Расшифровано:

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

echo "Расшифровано: $ (aws kms decrypt --ciphertext-blob fileb: ./ encrypted-file --query Plaintext --output text | base64 --decode)"
`
Пробовал с убунту. Если кто-то знает четкую документацию или примеры (ссылка на сайт или что-то еще), я был бы очень благодарен!

РЕДАКТИРОВАТЬ: получил шифрование и дешифрование, используя советы из этой статьи: https://dev.to/matchilling/pragmatic-storing-security-sensitive-data-using-aws-kms-5e5b

К вашему сведению, ссылка выше не работает, но статья кажется довольно полезной и доступна здесь .