1

Я получил ответ на свой первоначальный вопрос здесь, надеюсь, можно задать дополнительный вопрос, разместив еще один вопрос. Исходя из моего первоначального вопроса выше, я смог расшифровать предварительный главный секретный ключ / ключ клиента, используя свой закрытый ключ, как мне объяснили, используя

openssl rsautl -in cpre.key -inkey key.pem -decrypt -out spre.key

Это кажется довольно простым, и он создал 48-байтовый файл. Я понимаю, что то, что я делаю, не собирается дешифровать или шифровать трафик https, над которым я работаю небольшими шагами. Следующим шагом из моего чтения будет генерация главного секрета / ключа, и из ответа на мой предыдущий пост я, похоже, смогу сделать это и с openssl, с которым я немного изо всех сил пытаюсь это сделать. Я придумал вариант openssl dgst

echo -n 'значение' | openssl dgst -sha256 -mac hmac -macopt hexkey:$(hexkey)

где значение - "главный секрет"+client.random+server.random, а hexkey - мой расшифрованный предварительный главный секрет из предыдущего шага. Я правильно делаю этот шаг? Насколько я понимаю, RFC с тех пор как он впервые производит 32 байта, а RFC объясняет, что это будет 48 байтов. То, как я интерпретирую RFC, заключается в том, что мне нужно взять этот результат и передать его снова, что генерирует дополнительные 32 байта, из которых я беру первые 16 и объединяю их в конце первых 32, чтобы получить мои 48 байтов для главный секрет / ключ. Я полностью отключен на следующем шаге после того, как расшифровал и получил предварительный мастер-ключ на стороне сервера? Спасибо Дэвид Б

1 ответ1

0

Предварительно, я надеюсь, что вы на самом деле не сделали то, что показали. За исключением меток, все данные, используемые при получении ключа TLS, являются двоичными данными, которые не могут быть точно заданы в качестве аргумента команды shell echo или любой другой команды, кроме, возможно, встроенной версии в zsh если вы отключаете escape-символы и, конечно, не можете быть ' напечатано '(даже вырезано и вставлено) в буквальном аргументе с одинарными кавычками.

Если у вас есть данные в файлах, их можно использовать. Двоичные данные могут быть считаны из файлов и записаны в них - по крайней мере на платформах, поддерживаемых OpenSSL. Если у вас нет файлов (но есть каналы), вы можете обойти это, передав данные в шестнадцатеричном формате, за исключением -macopt hexkey: который уже принимает шестнадцатеричный формат , используя либо программу, такую как xxd -r , либо printf с гекс, сформированный в escape-символы, или echo с гексом, сформированным в непереносимые escape-коды, или хаки типа GNU sed s///e , или более общая программа awk или perl , для преобразования гекса в двоичный файл для ввода в openssl . И при необходимости аналогичные хаки для преобразования двоичного вывода в шестнадцатеричный, но dgst -mac hmac может выводить в шестнадцатеричном виде до тех пор, пока вы удалите blahblah=(sp) с фронта.

Более существенно, что запуск первого выхода HMAC обратно через себя дает только блоки «A», которые вы затем пропускаете через другой слой HMAC, чтобы получить фактический вывод «P_hash». См. Https://crypto.stackexchange.com/questions/46549/tls-1-2-prf-with-hmac-sha256, который по сути является тем же вопросом с использованием тестового вектора, опубликованного на https://www.ietf.org/mail-archive/web/tls/current/msg03416.html за исключением того, что я ответил на Java. Вот эквивалент командной строки OpenSSL:

$ echo $key; echo $lbsd # start from hex
9bbe436ba940f017b17652849a71db35
74657374206c6162656c a0ba9f936cda311827a6f796ffd5198c
$ echo $lbsd | xxd -r -p >a0
$ openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a0 -binary >a1
$ openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a1 -binary >a2
$ openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a2 -binary >a3
$ openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a3 -binary >a4
$ cat a1 a0 | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k1
$ cat a2 a0 | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k2
$ cat a3 a0 | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k3
$ cat a4 a0 | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k4
$ cat k1 k2 k3 k4 | head -c100 | xxd
0000000: e3f2 29ba 727b e17b 8d12 2620 557c d453  ..).r{.{..& U|.S
0000010: c2aa b21d 07c3 d495 329b 52d4 e61e db5a  ........2.R....Z
0000020: 6b30 1791 e90d 35c9 c9a4 6b4e 14ba f9af  k0....5...kN....
0000030: 0fa0 22f7 077d ef17 abfd 3797 c056 4bab  .."..}....7..VK.
0000040: 4fbc 9166 6e9d ef9b 97fc e34f 7967 89ba  O..fn......Oyg..
0000050: a480 82d1 22ee 42c5 a72e 5a51 10ff f701  ....".B...ZQ....
0000060: 8734 7b66                                .4{f

Если вы можете заставить свой код повторить это, он должен работать и для фактического рукопожатия TLS1.2, с корректной корректной длиной: 48 для главного секрета и в зависимости от набора шифров для рабочих ключей.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .