Обратный вызов пароля для чтения открытого ключа с помощью OpenSSL API

Question

При использовании криптографии с открытым ключом часто принято хранить закрытые ключи в зашифрованном формате, поскольку они, конечно, должны быть секретными.Это отражено в OpenSSL C API, который предоставляет функции наподобие PEM_write_PrivateKey, которые принимают в качестве аргументов функции необязательный шифр для шифрования ключа (например, AES).Затем, при считывании зашифрованного ключа обратно с диска, API OpenSSL предоставляет такие функции, как PEM_read_PrivateKey, что позволяет пользователю указывать указатель функции, используемый в качестве обратного вызова, чтобы приложение могло предоставить OpenSSL пароль для зашифрованного ключа.

Но что меня смущает, так это то, что API OpenSSL также позволяет пользователю предоставлять обратный вызов пароля при чтении ключа Public .Например, одна сигнатура функции API для чтения в открытом ключе:

 EVP_PKEY *PEM_read_PUBKEY(FILE *fp, EVP_PKEY **x,
                                        pem_password_cb *cb, void *u);

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

Answer 1

Как упомянуто в этом комментарии , любые данные в кодировке PEM могут быть зашифрованы.Шифрование сообщений для почты с повышенной конфиденциальностью (PEM) определено в RFC 1421 , и в контексте вашего вопроса интересно посмотреть пример сообщения в разделе 4.6 Сводка полей инкапсулированного заголовка

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
          B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
          E2EF532C65CBCFF79F83A2658132DB47

LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----END PRIVACY-ENHANCED MESSAGE-----

Глядя на ветку 1.1 OpenSSL, она имеет функцию PEM_read_bio(), которая поддерживает чтение такого сообщения и разбиение его на его имя (как указано в верхней строке).), заголовок (пары «имя-значение» ниже) и данные (материал, закодированный в base64):

 int PEM_read_bio(BIO *in, char **name, char **header,
                  unsigned char **data, long *len);

Все функции OpenSSL PEM_read_XYZ() в какой-то момент вызывают его, начиная с PEM_bytes_read_bio(), потому что все они реализованы одинаково с помощью макроподключений.Эта функция содержит следующие вызовы:

PEM_read_bio(bp, &nm, &header, &data, &len)

для разделения сообщения, затем

PEM_get_EVP_CIPHER_INFO(header, &cipher);

, чтобы выяснить, какой тип информации о шифровании находится в заголовке этого сообщения, и заполнитьEVP_CIPHER_INFO возразите с ним, а затем

PEM_do_header(&cipher, data, &len, cb, u);

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

Теперь, что может сбить с толку, это то, что определенные форматы закрытого ключа, такие как, например, PKCS # 8, также имеютих собственный механизм хранения информации шифрования, независимый от кодировки PEM.Технически говоря, должно быть возможно применить шифрование к таким ключам дважды: один раз на уровне PEM и один раз на уровне PKCS # 8.Инструменты OpenSSL для генерации или преобразования в отформатированные ключи PKCS # 8, похоже, не предлагают такую ​​возможность.Кроме того, ни один из инструментов, по-видимому, не предоставляет возможности шифрования любых сгенерированных файлов PEM с открытым ключом, кроме случаев, когда закрытый ключ также включен.

Вы можете проверить некоторые выходные данные, чтобы увидеть, соответствуют ли они моей истории.Сначала генерируем пару ключей RSA в формате PKCS # 1, без шифрования:

$ openssl genrsa
Generating RSA private key, 2048 bit long modulus (2 primes)
.................+++++
............+++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAlcnR/w7zPoLrhuqFvcfz5fn8DFb0fEcCKOKSj+x+JJxGth9P
rJbxkt4pRXxbMIL0fX59HN5bRvQh2g59l/kfr30kCOnclap9nRrohWyg2i7720Cw
<truncated>

Затем та же команда, но с использованием шифрования, которое происходит на уровне PEM, как вы можете видеть в заголовках:

$ openssl genrsa -des3
Generating RSA private key, 2048 bit long modulus (2 primes)
.....................+++++
....................+++++
e is 65537 (0x010001)
Enter pass phrase:
Verifying - Enter pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,D90861647707F687

DIupLghCjcvpLenqAAULaJj1EDvUUfc2Xc58YVh7rMTSVgLwZ+9CtnUQJcup4aUQ
a1EdGXTadwBQB2jTtiFJbH67/5D26PHXPnM+YN2rnoReOExVS7hKu3DTq7c4j6a3
<truncated>

Наконец, создается аналогичный ключ, но теперь для PKCS # 8, который имеет свое собственное шифрование и поэтому не шифруется на уровне PEM.Вы можете видеть, что там нет заголовков PEM.

$ openssl genpkey -algorithm RSA -des3
.........................................+++++
...........................................................................+++++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIV0Ih4bsI6egCAggA
MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECNOim8HAN8j5BIIEyEe05hHtc8HL
<truncated>

Если все мои рассуждения верны, то запрос «Введите пароль PEM» является неточным, поскольку это не шифрование уровня PEM, а PKCS# 8-уровневое шифрование.