On Thu, 25 Dec 2014 21:14:03 +0300 Max Dmitrichenko <[email protected]> wrote:
> 25 декабря 2014 г., 19:21 пользователь Никита Егоров > <[email protected]> написал: > > Имено с отечественной сертификацией дела не имел, поӕтому > > проесните, по какому алгоритму КриптоПРО подписывает документы? > > Какие могут быть альтернативы? Только ГОСТ. Альтернативы есть. Есть ГОСТ Р 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/20141226120419.5b3f4b94@fafnir
