Re: Отечественная криптография
On Thu, 25 Dec 2014 21:14:03 +0300
Max Dmitrichenko <dmitrmax@gmail.com> wrote:
> 25 декабря 2014 г., 19:21 пользователь Никита Егоров
> <khenarghot@gmail.com> написал:
> > Имено с отечественной сертификацией дела не имел, поӕтому
> > проесните, по какому алгоритму КриптоПРО подписывает документы?
>
> Какие могут быть альтернативы? Только ГОСТ.
Альтернативы есть. Есть ГОСТ Р 34.10-2001 и ГОСТ Р.34.10-2012. В
последнем предусмотрены ключи размером 256 бит и 512. Для 256 битных
ключей предусмотрено 3 набора параметров (совпадающих для обоих гостов)
и 5 их обозначений, для 512-битных - два набора параметров.
> Мне кажется, что сейчас придет Vitus Wagner и всё расскажет. Сто лет я
> уже не был в d-r, но если я правильно ошибаюсь, он даже в соавторах к
> RFC на GOST ) А значит, скорее всего, имеет отношение к разработке
Не, в соавторах RFC на ГОСТ меня нет. В соавторах тех RFC, которые
представляют собой просто перевод гостов, есть моя жена.
А я всего лишь автор той реализации, которая включена в дистрибутив
OpenSSL. И то уже с тех пор как я этим занимался, появились
неофициальные патчи, написанные другими людьми,
реализующие алгоритмы 2012 года.
В общем, общий принцип такой:
Для работы с юридически значимой электронной подписью нужно не просто,
чтобы поддерживался алгоритм ГОСТ, нужна сертифицированная ФСБ
реализация (это называется СКЗИ - средство криптографической защиты
информации). В сертификаты квалифицированной электронной подписи
полагается вписывать расширение, которое содержит название
используемого СКЗИ. То есть по хорошему счету сертификат на ключ
выдается для использования в определенном программном средстве и никак
иначе. Все, естественно, нарушают, но...
На рынке существуют минимум три сертифицированных СКЗИ, которые работают
в Debian. (возможно больше, но я внимательно этот вопрос не изучал).
1. Magpro CryptoPacket фирмы КриптоКом - модуль gost в OpenSSL
делался специально для того, чтобы можно было заменить его на
сертифицированную engine MagPro CryptoPacket поменяв одну строчку в
конфиге OpenSSL. Но все оказалось не так просто - для того чтобы
соответствовать требованиям сертификации, нужно чтобы libcrypto.so и
libssl.so тоже были из комплекта Криптопакета и их контрольные суммы
соответствовали приведенным в формуляре лицензионного СКЗИ.
2. CryptoPro CSP. Там не стали пытаться вписаться в существюущие
инфраструктуры криптобиблиотек Unix, а просто собрали под Unix CSP с
его микрософтовским API - пользуйся как хочешь. Хотя какие-то утилиты и
по-моему модуль с реализацией TLS для апача у них есть.
3. ЛИРССЛ фирмы LISSI - тоже изделие на базе OpenSSL. На сайте они
утверждают что уже сертифицировали алгоритмы 12-года. (у криптопро
версия 4.0 уже в стадии публичного бетатестирования, но еще не
сертифицирована)
Это что касается чисто программных решений. Есть еще
Рутокен фирмы Aktiv. Там поставляется PKCS11 модуль, который работает в
Linux и приведены инструкции по использованию токена с OpenSSL.
Изготовить заявку на сертификат, удовлетворяющую требованиям
российского законодательства с помощью OpenSSL вполне можно. Но
потребуется немножко повозиться. Во-первых, нужно будет научиться
генерировать с помощью OpenSSL заявки, содержащие русские буквы в полях
DN. Там это довольно замысловато и по умолчанию не включено.
Во-вторых, нужно знать и прописать в конфиг OpenSSL OID-ы для
специфически российских сущностей, таких как СНИЛС, ИНН и ОГРН, которые
в сертификатах квалифицированной электронной подписи, насколько я знаю,
обязательны.
Поставляют ли вышеуказанные поставщики сертифицирвоанных решений
какие-то инструменты, облегчающие эту задачу, я не в курсе. Я из
криптокома ушел уже 4 года назад, и внимательно за развитием продуктов
не следил.
Вот некоторые выжимки из конфига openssl с одной из моих тестовых машин
Утверждать что там все правильно не буду. Заявки, сгенерированные с
использованием этого конфига я еще не давал на подпись в настоящие УЦ.
По значениям приведенных OID-ов можно нагуглить документы,
регламентирующие их использование.
[ new_oids ]
# Russian pension security number. Numeric string
SNILS = 1.2.643.100.3
# Organization number in the state registry (for organizations or individual
# businessmen) Numeric string
OGRN = 1.2.643.100.1
# Individual insurance number (Numeric String)
INN = 1.2.643.3.131.1.1
# cert extension to indicate subject sign tool (value - utf8 string)
subjectSignTool=1.2.643.100.111
# sequence of four utf8 strings
issuerSignTool=1.2.643.100.112
#POLICY idendentifiers for russian cryptography certification classes
# if policy includes oid of more secure class, it shoud include all
# identifiers of all less secure classes. I.e KC2 - both KC1 and KC2,
# most secure KA1 - all six
KC1=1.2.643.100.113.1
KC2=1.2.643.100.113.2
KC3=1.2.643.100.113.3
KB1=1.2.643.100.113.4
KB2=1.2.643.100.113.5
KA1=1.2.643.100.113.6
[ req ]
# Default_bits parameter is applicable for RSA only
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = rus_dn
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = utf8only
utf8=yes
[ rus_dn ]
countryName = Country Name (2 letter code)
countryName_default = RU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (2-digit Numeric Code)
stateOrProvinceName_default = 77 Москва
stateOrProvinceName_min = 2
stateOrProvinceName_max = 40
localityName = Locality Name (eg, city)
streetAddress = StreetAddress
organizationName = Organization Name (eg, company)
organizationName_default = Моя контора
SNILS = SNILS (for person only)
OGRN = OGRN (for organization only)
INN = INN (for organization only)
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
Reply to: