Спорове със съседи 

Сертификат с мек корен на Lissy. Wiki секции

Системни изисквания

  • достъп до интернет
  • Операционна система: Windows 8, 7, XP SP 3/2
  • Процесор: 1,6 GHz или по-висок
  • RAM: 512 MB
  • Наличие на един от поддържаните крипто доставчици: CryptoPro CSP 3.6 или по-нова версия, LISSI CSP, VIPNet CSP, Signal-COM CSP
  • Разделителна способност на екрана: минимум 800x600 px

Използвайте сертифициран доставчик на крипто

За работата на програмата Ekey.Signature е задължително наличието на работното място на криптографски инструмент за защита на информацията (CIPF), който криптира документи в съответствие с алгоритмите на GOST. CryptoPro CSP системи не по-ниски от 3.6, LISSI CSP, VIPNet CSP, Signal-COM CSP могат да се използват като CIPF.

Инструментите за криптографска защита на информацията са съвместими с Ekey.Signature, но са несъвместими един с друг. На едно работно място може да се инсталира само един CIPF.

Използвайте антивирусна програма

Инсталирайте популярна антивирусна програма на работното си място и я актуализирайте редовно. Антивирусната програма предпазва от вируси, шпионски софтуер и елиминира сама повечето заплахи за сигурността.

Защитете достъпа до вашия електронен подпис и работното място с парола

Като използвате Ekey.Signature и инструменти за криптографска защита, предпазете компютъра си от физически достъп от непознати. Използвайте парола за достъп.

За достъп до електронния подпис използвайте сложна парола. Добрата парола е гарантирана сигурност на вашите данни. Добър начин да запомните парола е да я въвеждате постоянно, когато извършвате операции с електронен подпис.

Страхотно място за съхранение на вашата парола е вашата памет. Не е препоръчително да записвате паролата никъде. Не съхранявайте паролата до физическия носител на електронен подпис, не съхранявайте паролата в системата.

Използвайте само лицензирани и актуални програми

Периодично програмите, инсталирани на вашето работно място, се актуализират, за да подобрят стабилността и сигурността на вашата работа.

Инсталирайте софтуерни актуализации само от официални сайтове, проверете адресите на сайтовете и информацията за издателя на програмата, преди да инсталирате.

Ekey инсталация. Подпис

1. Изтегляне

2. За да започнете инсталирането на програмата, стартирайте инсталационния файл. Ако UAC е стартиран, трябва да разрешите промени в програмата Ekey Transfer.

Подготовка на файлове за Rosreestr

1. Изберете типа операция "Rosreestr" в главния прозорец на програмата или в контекстното меню на файла.


3. Добавете отчет с помощта на бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файл с помощта на мишката.
4. Щракнете върху бутона Генериране.
6. След като операцията приключи, файлът за подпис ще бъде записан в същата директория като оригиналния файл, отделеният файл за подпис е валиден само ако оригиналният файл присъства.

Подготовка на контейнер за FFMS на Русия, Службата на Банката на Русия, Централната банка

1. Изберете типа транзакция "FFMS на Русия".

2. Изберете личен сертификат.

3. Добавете отчет с разширение xtdd или smcl, като използвате бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файла с мишката.

5. Ако е необходимо, въведете паролата за контейнера с личен ключ

7. За да добавите подпис, прикачете предварително генерирания контейнер, изберете необходимия сертификат и щракнете върху бутона Генериране.

8. За да изпратите отчети до портала на Службата на Банката на Русия (FFMS), щракнете върху бутона за добавяне, в менюто, което се показва, изберете необходимия контейнер с отчета и щракнете върху бутона за качване в портала.

FSIS TP Министерство на регионалното развитие на Русия

1. Изберете типа операция "FSIS TP".

2. Изберете личен сертификат.

3. Добавете отчет с помощта на бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файл с помощта на мишката.

4. Щракнете върху бутона Генериране.

5. Ако е необходимо, въведете паролата за контейнера с личен ключ

6. В менюто за запазване, което се показва, изберете място за запазване на резултата от операцията.

Регистър на Роскомнадзор (zapret-info.gov.ru)

1. Изберете операцията регистър Roskomnadzor

2. Изберете личен сертификат

3. За да разберете времето на последната актуализация на системния регистър, щракнете върху „Час на последната актуализация на разтоварването от системния регистър“

4. За да изпратите заявка, щракнете върху „изпрати заявка“

Попълнете полетата, за да генерирате заявка.

5. За да получите резултата от обработката на заявката, щракнете върху „Заявка за получаване на резултата“

За автоматично разтоварване на регистъра трябва да поставите отметка в квадратчето „Разтоварване автоматично“, да зададете необходимия период за разтоварване и да посочите директорията, в която да запазите резултатите от разтоварването.

ISED

1. Изберете тип операция "ISED".

2. Добавете отчет с помощта на бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файл с помощта на мишката.

3. Изберете сертификати на получател

4. Щракнете върху бутона Генериране.

5. В менюто за запазване, което се показва, изберете място за запазване на резултата от операцията.

Подпис на файла

1. Изберете тип операция "Подписване ръчно".

2. Изберете личен сертификат.

4. Изберете желаните опции за подпис.

5. Щракнете върху бутона "Подписване".

6. Ако е необходимо, въведете паролата за контейнера с личен ключ

Обяснения:

Запазете подписа в отделен файл

Когато флагът е зададен, ще бъде създаден незакрепен електронен подписАко флагът не присъства, подписът ще бъде добавен в края на файла (в този случай документът и електронният подпис ще се съхраняват заедно)

Архивни файлове

Трябва ли да архивирам файлове след подписване

Разширение - Разширението на файла за подпис по подразбиране е sig, можете също да посочите свое собствено разширение

Кодиране - Изберете кодирането, от което се нуждаете Der или Base-64

Деактивирайте заглавките на услугата- Ако е избрано кодиране Base-64 (Заглавките се използват за съвместимост с трета страна софтуер).

Криптиране на файлове

1. Изберете типа операция „Шифроване ръчно“.

2. Изберете личен сертификат.

3. Добавете файл с помощта на бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файл с помощта на мишката.

4. Изберете необходимите опции за криптиране.

5. Добавете или изберете от наличните сертификати на получател (на когото файлът ще бъде криптиран)

6. Щракнете върху бутона "Шифроване".

7. Ако е необходимо, въведете паролата за контейнера с личен ключ

8. В менюто за запазване, което се показва, изберете място за запазване на резултата от операцията. Обяснения:

Кодиране

Изберете Der или Base-64 кодиране, от което се нуждаете

Разширение

Разширението, което ще има крайният файл (enc по подразбиране), можете също да посочите свое собствено разширение. Деактивиране на заглавките на услугата - Ако е избрано кодиране Base-64 (изисква се за съвместимост със софтуер на трети страни).

Архивирайте файлове преди криптиране

Ако трябва да архивирате файлове преди криптиране, поставете отметка в съответното квадратче.

Ако добавите няколко файла, всички файлове ще бъдат опаковани в един архив.

Дешифриране на файлове

1. Изберете типа операция "Декриптиране".

2. Изберете личен сертификат.

3. Добавете файл с помощта на бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файл с помощта на мишката.

4. Щракнете върху бутона "Декриптиране".

5. Ако е необходимо, въведете паролата за контейнера с личен ключ

6. В менюто за запазване, което се показва, изберете място за запазване на резултата от операцията.

Проверка на подписа

1. За да започнете проверката на подписа, използвайте удобния за вас метод за проверка.

  • Чрез двукратно щракване върху файла, съдържащ подписа.
  • Изберете типа операция "Проверка на подписа" в главното меню на програмата.
  • Чрез контекстното меню на файла, който ще се проверява.

2. Добавете файл с помощта на бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файл с помощта на мишката.

3. Щракнете върху бутона Проверка.

След натискане на бутона "Проверка" се появява прозорец с резултата от проверката на подписа. В него можете да видите дървото на подписите, да отпечатате резултата от проверката и да отворите изходния файл за преглед.

Също така по време на сканирането можете да видите съдържанието на файлове с разширение: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif.

Обяснения:

Отмяна на подписа на файлове

Ако е създаден прикачен подпис, тази опция може да се използва за получаване на изходен файл, който не съдържа никакви подписи.

Добавяне на подпис

1. Изберете типа операция "Добавяне на подпис".

2. Изберете личен сертификат.

4. Щракнете върху бутона "Подписване".

5. Ако е необходимо, въведете паролата за контейнера с личен ключ

6. В менюто за запазване, което се показва, изберете място за запазване на резултата от операцията.

Проверете подписа

1. Изберете тип операция "Удостоверяване на подпис".

2. Изберете личен сертификат.

3. Добавете файл с подпис чрез бутона „Прикачване на файл(ове)“ или плъзнете и пуснете файла с помощта на мишката.

4. Щракнете върху бутона Потвърди.

5. Ако е необходимо, въведете паролата за контейнера с личен ключ

6. В появилото се меню изберете подписа, който искате да заверите

7. В менюто за запазване, което се показва, изберете място за запазване на резултата от операцията.

Автоматична актуализация

Когато актуализацията стане достъпна, в горния десен ъгъл на стартираното приложение Ekey Signature се появява съответен надпис. За да започнете актуализация, щракнете върху него с левия бутон на мишката.

След като процесът на актуализиране приключи, щракнете върху „OK“ при съобщението, че някои промени ще влязат в сила само след рестартиране. Кликнете върху бутона "Край". След това се препоръчва да рестартирате компютъра. На първо място е необходимо рестартиране, за да влязат в сила актуализациите, свързани с работата на контекстното меню на Windows.

Автоматично инсталиране на основни сертификати

Ако в магазина няма основен сертификат, когато се стартира приложението Ekey Signature, в потребителския дневник се показва съответната грешка. В този случай трябва да подпишете файл с "проблемно" лично удостоверение. Когато извършвате операцията по подписване, ще се покаже диалогов прозорец с молба да инсталирате липсващия главен сертификат. Щракнете върху Да, за да инсталирате липсващия основен сертификат.

Сертифициращ орган CAFL63създадена на базата на . СУБД SQLite3 се използва за съхраняване на данни (заявки, сертификати, настройки и др.). Сертифициращият орган разполага с графичен интерфейс, разработен в Tcl/Tk.

CAFL63 CA е разработен, като се вземат предвид изискванията федерален закон 6 април 2011 г № 63-FZ „За електронния подпис“, както и „Изисквания за формата квалифициран сертификатключ за проверка на електронния подпис”, одобрен със заповед на Федералната служба за сигурност на Русия от 27 декември 2011 г. № 795.

СО включва Регистрационен център (ЦР), който отговаря за приемането на заявления за удостоверения от граждани. Днес се издават сертификати за юридически лица, физически лица и индивидуални предприемачи. Заявления се приемат в в електронен форматвъв формат PKCS#10, CSR (заявка за подписване на сертификат) или SPKAC. Имайте предвид, че CSR форматът е PKCS#10 PEM-кодирана заявка със заглавка -----BEGIN REQUEST CERTIFICATE-----.

Заявката представлява попълнен въпросник, целите, за които е необходим сертификат, публичен ключ на потребителя, заверен (подписан) с частния ключ на потребителя. Освен това, с пакет от документи, доказващи по-специално самоличността на заявителя, и с електронен носител, на който се съхранява искането (подчертавам, че искането, по-добре е частният ключ да се съхранява другаде), гражданинът идва към КР на ТЗ.

CR проверява документите, заявката (попълнени данни, коректност на електронния подпис и др.) и ако всичко е минало добре, приема заявката, одобрява я и я предава на Удостоверителния център (УЦ).

В случай, че заявителят дойде без готова заявка, тогава той, заедно със служителя на CR, отива в отделна работно мястокъдето се изготвя искането за сертификат. Подготвена заявка за електронна медия, както вече споменахме, влиза в CR. Какво трябва да запомни кандидатът тук? Първо и най-важно: кандидатът трябва да вземе носителя с генерирания частен ключ!

Одобрената заявка на електронен носител се предава на УО, където се издава удостоверение въз основа на нея.

Това е принципна схема на работата на UC. Подробностите ще станат ясни по-долу. Една забележка, в името на удобството при демонстриране на помощната програма за подготовка на заявки, CR и CA са комбинирани в един демонстрационен комплекс. Но няма проблеми с разделянето на функционалността. Най-простото решение е да имате копие на CAFL63 на всяко работно място и да използвате само необходимата функционалност.

Когато проектът беше в разгара си, проектът SimpleCA привлече вниманието ми. Проучването на този проект беше много полезно за окончателното внедряване на CAFL63 CA.

Изтеглете CAFL63 дистрибуция за Win32/Win64, Linux_x86/Linux_x86_64 платформи.

И така, стартираме помощната програма CAFL63 - на екрана се появява началната страница на CAFL63:

Започваме работата с натискане на бутона "Създаване на БД". CA базата данни се създава с помощта на кросплатформената СУБД SQLite3. Базата данни на CA съдържа няколко таблици. Основната таблица - mainDB - съдържа само един запис, който съхранява основния сертификат, частен ключ, криптиран с парола, и настройки на CA. Има две таблици, свързани със заявките за сертификати: reqDB текущи заявки и reqDBArc архив на заявките. Създават се три таблици за сертификати: новата таблица за сертификати certDBNew, таблицата за архивиране на сертификати CertDB и таблицата за анулиране на сертификати CertDBRev. Всички таблици със заявки и сертификати използват хеш стойността (sha1) на публичния ключ като първичен ключ. Това се оказа много удобно, например при търсене на сертификат при поискване или обратно. В базата данни има друга таблица crlDB, която съхранява списъци с отменени сертификати. И така, щракнахме върху бутона „Създаване на DB“:

Създаването на CA започва с избор на директория, в която ще съхраняваме базата данни и задаване на парола за достъп до частния ключ на CA. С натискане на клавиша "Напред" отиваме на страницата за избор на типа и параметрите на двойката ключове за CA:

След като решихме двойката ключове за основния сертификат на създавания сертифициращ орган, продължаваме да попълваме формуляра с информация за собственика (пропуснахме първата екранна снимка):

Имайте предвид, че помощната програма CAFL63 има определена "интелигентност" и следователно контролира не само наличието на данни в полетата, но и коректността (червено подчертаване - неправилно) на попълване на такива полета като TIN, OGRN, SNILS, OGRNIP, адрес електронна пощаи т.н.

След като попълните полетата с информация за собственика на CA, ще бъдете помолени да вземете решение относно системните настройки на CA:

Ако няма да работите с руска криптография, тогава можете да използвате обикновен OpenSSL. За да работите с руската криптография, трябва да посочите подходящата версия, модификация на OpenSSL. Прочетете README.txt в изтегленото разпространение за повече подробности. Също така, в съответствие с FZ-63, се предлага да се зададе информация за сертифицирането на самия СО и използвания от него CIPF.

След като попълните правилно всички полета, ще бъдете помолени отново да проверите тяхната валидност и да кликнете върху бутона „Край“:

След натискане на бутона "Край" ще бъде създадена CA база данни, в която ще бъдат записани: основният CA сертификат, частен ключ, системни настройки. И началната страница на помощната програма CAFL63 ще се появи отново на екрана. Сега, след като сме създали базата данни на новосъздадения CA, натискаме бутона "Open DB", избираме директорията с базата данни и влизаме в главния работен прозорец на CA:

Щраквайки върху бутона „Преглед на CA CA“, се уверяваме, че това е основният ни сертификат.

Следващата стъпка е изготвянето на шаблони/профили за кандидатстване за юридически лица, физически лица и индивидуални предприемачи ( Инструменти->Настройки->Типове сертификати->Нови ):

След като зададете името на новия профил, ще бъдете подканени да определите неговия състав:

След изготвяне на профилите, СО има готовност да приеме кандидати и заявления от тях. Както беше отбелязано по-горе, кандидатът може да дойде със или без попълнено заявление за сертификат.

Ако кандидатът дойде с попълнено заявление, след проверка на документите му, заявлението се импортира в базата данни на СО. За да направите това, в главния работен прозорец изберете раздела „Заявки за сертификати“, щракнете върху бутона „Искане за импортиране / CSR“ и изберете файла със заявката. След това ще се появи прозорец с информация за заявката:

След като прегледате заявката и се уверите, че е попълнена коректно, можете да натиснете бутона „Импортиране“, за да я въведете в базата данни. Веднага отбелязваме, че когато се опитате да въведете отново заявката в базата данни на CA, ще се покаже съобщение:

Заявките в базата данни на CA са маркирани (колоната „Тип“) или като „Locale“, създадени от CA, или като „Import“, създадени от самия заявител, а също и часът на получаване на приложението от CA записано. Това може да бъде полезно при справяне с конфликтни ситуации.

Ако кандидатът дойде без заявление и поиска да го създаде, тогава на първо място е необходимо да се реши ( Настройки->Типове сертификати->Индивидуални->Редактиране ) с тип двойка ключове ( -> Двойка ключове ), с каква цел ( -> Използване на ключ ) изисква се сертификат:

Двойката ключове може да бъде създадена или чрез CIPF „LIRSSL-CSP“ (бутон OpenSSL) и записан във файл, или на PKCS#11 токен (бутон PKCS#11). В последния случай трябва също да посочите библиотеката за достъп до токена (например rtpkcs11ecp за RuToken ECP токена или ls11cloud за).

След като сте избрали профила и щракнете върху бутона "Напред", по-нататъшната процедура не се различава много от издаването на основен сертификат. Една важна забележка: запомнете къде съхранявате частния ключ и паролата за достъп до ключа. Ако PKCS#11 токен/смарткарта се използва като CIPF за генериране на двойка ключове, тогава тя трябва да бъде свързана към компютър:

Създаденото или импортирано приложение се намира в базата данни на CA и се показва в главния прозорец в раздела „Заявки за сертификати“. Получените заявки са в режим на "разглеждане" (колона "Статус" на разделите "Заявки за сертификати" и "Архив на заявките"). За всяка новопостъпила заявка трябва да се вземе решение (контекстно меню, когато щракнете с десния бутон върху избраната заявка):

Всяка заявка може да бъде отхвърлена или одобрена:


Ако заявката бъде отхвърлена, тя се премества от текущата таблица на заявките на reqDB в таблицата с архив на заявките reqDBArc и съответно изчезва от раздела Заявки за сертификати и се появява отново в раздела Архив на заявките.

Одобреното приложение остава в таблицата reqDB и в раздела „Заявки за сертификати“, докато сертификатът бъде издаден, след което също попада в архива.

Процедурата за издаване на сертификат, елементът от менюто „Издаване на сертификат“) се различава малко от процедурата за създаване на приложение:

Издаденият сертификат веднага се появява в раздела "Сертификати". В този случай самият сертификат влиза в таблицата certDBNew на CA базата данни и остава там, докато не бъде публикуван. Сертификатът се счита за публикуван, след като бъде експортиран в SQL дъмп на нови сертификати, който се прехвърля към публична услуга. Публикуването на сертификат го премества от таблицата certDBNew в таблицата certDB.

Ако натиснете десния бутон на мишката върху избрания ред в раздела „Сертификати“, ще се появи меню със следните функции:

Ако заявката е създадена в CA с генериран и записан във файл ключ, тогава трябва да създадете контейнер PKCS # 12 и да го изпратите на заявителя:

Трябва да обърнете внимание на "приятелското име" - кавичките в него трябва да бъдат екранирани:

След като защитеният контейнер PKCS#12 бъде създаден, файлът с частен ключ на заявителя се унищожава.

И така, CA започна своя живот, издаде първия сертификат. Една от задачите на КО е да организира свободен достъп до издадените удостоверения. Публикуването на сертификати по правило минава през уеб услуги. CAFL63 също има такава услуга:

За да публикува сертификати и списъци с отменени сертификати в публична услуга, CA или предварително качва сертификати във файлове (Сертификати->Експортиране на сертификати), или прави SQL дъмп на цялата таблица със сертификати, от която можете да създадете база данни със сертификати и качете списък със сертификати в него и впоследствие направете SQL дъмп на нови сертификати, от който те ще бъдат добавени към базата данни на обществената услуга:

Основната функция на КО е публикуването на списък с прекратени удостоверения, подобно на това, което прави МВР по отношение на изтеклите паспорти. Сертификатът може да бъде анулиран по искане на собственика. Основната причина за отмяна е загубата на частния ключ или загубата на доверие в него.

За да отмените сертификат, просто го изберете в раздела "Сертификати", щракнете с десния бутон и изберете елемента от менюто "Отмяна на сертификат":

Процедурата за прекратяване е същата като при създаване на заявка или издаване на удостоверение. Анулираният сертификат влиза в таблицата cerDBRev на базата данни на CA и се появява в раздела Отменени сертификати.

Остава да разгледаме последната функция на CA - освобождаването на CRL - списък с отменени сертификати. CRL списъкът се генерира в раздела „Отменени сертификати“, като щракнете върху бутона „Създаване на COS/CRL“. Всичко, което се изисква тук от администратора, е да въведе паролата на CA и да потвърди намерението си да издаде CRL:

Издаденият CRL влиза в таблицата crlDB на базата данни и се показва в раздела CRL/COS. За да видите CRL или да го експортирате с цел публикуване в обществена услуга, трябва, както винаги, да изберете желания ред, да натиснете десния бутон на мишката и да изберете елемента от менюто:

Изтеглете дистрибуция CAFL63за платформи Win32/Win64, Linux_x86/Linux_x86_64 . Освен това всичко работи успешно на платформата Android.

Читателите са поканени да изследователска работа, по време на който бяха идентифицирани редица проблеми с използването на инструменти за цифров подпис, които възникват за потребителите на Linux. По-специално бяха открити следните не съвсем очевидни точки:

  • възможност за получаване и използване на личен електронен сертификат цифров подписза достъп до обществени услуги днес се предоставя само срещу заплащане от търговски организации;
  • носители на данни за електронен подпис, издадени на крайни потребители от различни упълномощени организации, може да са несъвместими както помежду си, така и с портали, предоставящи достъп до услуги, включително публични;
  • нивото на сигурност на носителите на данни за електронен подпис, масово издавани на крайни потребители, като правило е значително намалено по отношение на наличното днес технологично ниво;
  • за повечето потребители на ОС от Регистъра на местния софтуер, EDS механизмите на Единния портал за обществени услуги не са достъпни поради несъвместимостта на софтуера EPGU и софтуера на оторизирани организации, издаващи сертификати за личен електронен подпис;
  • в някои случаи разработчици на предоставяне на портали обществени услуги, препоръчваме да използвате операционни системи, които не са включени в регистъра, както и софтуерни инструменти и конфигурации, които съзнателно намаляват сигурността на потребителските данни.

Авторите на работата очакват получените резултати да бъдат полезни за потребителите на решения, които използват EDS механизми, интеграторите, внедряващи съответните решения, а също така ще бъдат взети под внимание от организациите, отговорни за предоставянето на обществени информационни услуги и за внедряването на специфични EDS инфраструктурни механизми, както и разработчици на съответния софтуер и хардуер.

За какво става дума

Статията е посветена на поддръжката на електронен цифров подпис (EDS) на документи в ALT OS, както и на спецификата на използването на EDS в Руската федерация.

Основната задача е да се разбере какво трябва да направи един „обикновен потребител“™ - без значение дали е физическо или юридическо лице - действайки на обща основа, за да използва пълноценно възможностите на електронните платформи за търговия и порталите за обществени услуги, докато работещи в ОС от регистъра на местния софтуер. „Пълно използване“ означава преди всичко възможността за удостоверяване на съответния сайт с помощта на сертификат, поставен на отделен физически носител, и възможността за електронно подписване на документи, генерирани в интерфейса на сайта.

Вече са проведени редица изследвания по тази тема, резултатът от които е заключението, че по принцип всичко работи. Тук е важно да се разбере, че повечето от изследванията за съвместимост с порталите на държавните служби на Руската федерация на съвременни криптографски инструменти, работещи под операционната система Linux, са извършени в лабораторни условия. Например, ако има специални споразумения между изследователя и сертифициращия орган, който издава сертификата. За съжаление, въз основа на резултатите от такава работа е трудно да се преценят реалните възможности на хората, действащи на обща основа.

Как работи всичко

За да влезете в сайта, без да въвеждате потребителско име и парола, а просто чрез свързване на хардуерен токен към USB конектора, е необходимо специализиран софтуерен стек да работи правилно в операционната система: поддръжка на физически устройства, криптографски алгоритми, софтуерни интерфейси , формати и комуникационни протоколи. В същото време съвместимостта на криптографските алгоритми, формати и протоколи трябва да бъде осигурена и извън зоната на отговорност на ОС - в сертифициращия орган, който издава сертификата, и на сайта, на който е необходимо да се предостави достъп.

И ако говорим за уебсайтове на държавни агенции, също е необходимо използваните криптовалути да бъдат сертифицирани за подходяща употреба в Руска федерация.

Основни механизми

Технологията EDS, официално използвана в Руската федерация, се основава на инфраструктура с публичен ключ. Нека да разгледаме как работи с пример.

За по-голяма яснота нека разгледаме механизма на действие на универсалните алгоритми, подходящи както за електронен подпис, така и за криптиране. Тези алгоритми, наред с други неща, включват интернет стандарта RSA и руския GOST R 34.10-94, който беше в сила в Руската федерация като стандарт за електронен подпис до 2001 г. По-модерните EDS алгоритми, които включват, наред с други неща, текущите GOST R 34.10-2001 и GOST R 34.10-2012, като правило, са специализирани. Те са предназначени изключително за подписване на документи и не са подходящи за криптиране. Технически разликата между специализираните алгоритми е, че хешът в техния случай не е криптиран. Вместо да се криптира, върху него се извършват и други изчисления с помощта на частния ключ, резултатът от които се съхранява като подпис. Когато се проверява подпис, съответните допълнителни изчисления се извършват с помощта на публичния ключ. Загубата на универсалност в този случай е плащане за по-висока криптографска сила. Примерът по-долу с универсален алгоритъм е може би малко по-малко подходящ, но вероятно по-разбираем за неподготвен читател.

Подпис на документа

И така, за формиране на електронен подпис в инфраструктура с публичен ключ се използва асиметрична схема за криптиране, която се характеризира с използването на двойка ключове. Това, което е криптирано с един от тези ключове, може да бъде декриптирано само с другия ключ от двойката. Един от ключовете на двойката се нарича таен или частен и се пази възможно най-тайно, другият се нарича публичен или отворен и се разпространява свободно - като правило, като част от сертификат. В допълнение към ключа сертификатът за електронен подпис включва информация за собственика на сертификата, както и подписа на ключа, заедно с информация за собственика, направена от доверена страна. По този начин сертификатът вече съдържа електронен подпис, потвърждаващ, че информацията за собственика съответства на неговата двойка ключове.

Организационно този подпис се извършва от сертифициращ орган (CA) - юридическо лице A, на който е делегирано правомощието да установи и потвърди дали собственикът и ключът съвпадат. Съответствието се установява след представяне на документи на хартиен носител и се потвърждава именно с електронен подпис, което е удобно да се разгледа само чрез примера за изготвяне на сертификат.

Сертифициращият орган за подписване на клиентски сертификати също има чифт ключове. Потвърдената информация за собственика на сертификата под формата на специално създадена таблица се комбинира в един документ с неговия публичен ключ. След това този документ преминава през две трансформации. Първо, хеш функцията превръща документа в уникална последователност от символи с фиксирана дължина (хеш). След това полученият хеш се криптира с частния ключ на сертифициращия орган. Резултатът от криптирането е действителният електронен подпис. Той се прикрепя към подписания документ, в случая информация за потребителя и неговия ключ, и се разпространява заедно с него. Всичко това заедно - документ с информация за потребителя и неговия публичен ключ, както и подписването на този документ с публичния ключ на УО, се съставя по специален начин и се нарича потребителски сертификат.

Точно както в случая с потребителските данни като част от сертификат, се издава електронен подпис на всеки друг документ. Например файл със заявление за услуга. Файлът се хешира, полученият хеш се криптира със секретния ключ на потребителя и се прикачва към документа. Резултатът е подписан документ.

Проверка на подписа

Както обикновено се случва с асиметричното криптиране, това, което е криптирано с един ключ, може да бъде декриптирано само от другия ключ от двойката. Така че, в случай на сертификат, криптираният хеш на документ, съдържащ публичния ключ на потребителя и проверена информация за потребителя, може да бъде дешифриран с помощта на публичния ключ на сертифициращия орган, който се разпространява безплатно като част от сертификата на сертифициращия орган. Така всеки, който получи CA сертификат, ще може да получи дешифрирания хеш от потребителския сертификат. Тъй като хеш функцията дава уникален резултат, като я приложите към документ, съдържащ публичния ключ на потребителя и информация за него, можете да проверите дали тези два хеша съвпадат. Ако са, тогава имаме същия документ, който е подписан от удостоверителния център и информацията, съдържаща се в него, може да се вярва. Ако не, тогава подписът не съвпада с документа и имаме фалшив.

Ситуацията с проверката на CA сертификата е абсолютно същата - той също е подписан с някакъв ключ. В резултат на това веригата от подписани сертификати завършва с "основен" сертификат, който е самоподписан. Такъв сертификат се нарича самоподписан. За официално акредитирани сертификационни центрове на Руската федерация основният сертификат е сертификатът на Главния сертификационен център на Министерството на телекомуникациите и масовите комуникации.

В допълнение към информацията за потребителя и неговия публичен ключ, сертификатът съдържа някои допълнителни данни - по-специално срокът на валидност на сертификата. Ако поне един сертификат във веригата е изтекъл, подписът се счита за невалиден.

Освен това подписът ще се счита за невалиден, ако клиентският сертификат бъде отменен от CA. Възможността за отмяна на сертификат е полезна, например, в ситуации, когато секретният ключ е изтекъл. Подходяща е аналогия с контакт с банка в случай на загуба на банкова карта.

Услуги на сертификационни центрове

И така, сертифициращият център със своя подпис потвърждава съответствието на определен публичен ключ с определен набор от записи. Теоретично разходите на CA за подписване на един сертификат са близки до нула: самият подпис е добре автоматизирана, не много скъпа изчислителна операция на модерно оборудване. В същото време услугите на UC са платени. Но за разлика от CA, които издават сертификати за уебсайтове, тук парите не се правят изцяло от нищото.

Първият компонент на цената на сертификата са режийните разходи за обслужване на акредитиран УО. Това включва: разходите за CA сертификат, който също се заплаща, разходите за лиценз за сертифициран софтуер, разходите за осигуряване на организационни мерки за защита на личните данни и др. Така се определя цената например на личен сертификат индивидуален. Което прави възможно подписването на локални файлове, документи на уебсайтове за обществени услуги и пощенски съобщения.

Вторият компонент на цената на сертификата се появява, когато потребителят иска да използва своя сертификат, например, за работа на електронни платформи за търговия. Според действащата нормативна уредба сайтът на електронната платформа за търговия удостоверява клиента, ако вече са изпълнени две условия: първо, разбира се, ако сертификатът не е изтекъл, сертификатът не е прекратен и подписът му е валиден. И второ, ако сертификатът ясно посочва, че е предназначен за работа на конкретен сайт. Записът за това изглежда като обикновен запис в същата таблица, която съхранява останалите данни от сертификата. За всеки такъв запис във всеки потребителски сертификат сертифициращият център дава определена сума. Което иска да компенсира за сметка на собственика на удостоверението. Следователно сертификатите, които позволяват достъп до електронни платформи за търговия, са по-скъпи.

Заплахи и атаки

За разлика от криптирането, при електронния подпис основната задача на атакуващия не е да получи дешифрирания текст, а да може да фалшифицира или произведе електронен подпис на произволен документ. Тоест, относително казано, не към дешифриране, а към криптиране. Условно – защото съвременните специализирани алгоритми за цифров подпис, както споменахме по-горе, не криптират хеша на документа, а извършват над него сходни по смисъл, но технически различни математически операции.

Съгласно стандартите, приети в Руската федерация, при електронно подписване на документи се използват криптографски алгоритми, които съответстват на Държавен стандарт RF (GOST R). Към момента на писане на този текст (втората половина на 2016 г.) за нито един от алгоритмите, свързани с EDS и имащи статут на стандарт в Руската федерация, не са известни методи за атака, които значително се различават по трудоемкост от простото изброяване. На практика това означава, че е по-лесно за атакуващ, чието ниво на достъп до изчислителни ресурси е по-ниско от това на голяма държава, да се опита да открадне ключа, отколкото да хакне алгоритъма и да фалшифицира подпис.

По този начин, в случай на електронен подпис, основните вектори на атака са насочени към получаване на секретния ключ от нападателя. Ако ключът се съхранява във файл на диска, той може да бъде откраднат по всяко време чрез получаване на подходящ достъп за четене. Например с помощта на вирус. Ако ключът се съхранява в криптиран вид, той може да бъде получен в момента на кандидатстване – например когато програмата, която извършва електронния подпис, вече е дешифрирала ключа и обработва данните с него. В този случай задачата става много по-сложна - трябва да намерите уязвимост в програмата или ще трябва сами да дешифрирате ключа. Въпреки значителното усложняване на задачата, тя все още остава съвсем реална. За специалистите в съответната област той спада към категорията на рутинните.

Възможно е още повече да се усложни задачата за получаване на таен ключ от нападател, като се постави секретният ключ на отделен хардуерен носител по такъв начин, че ключът никога да не напуска границите на това физическо устройство. В този случай нападателят може да получи достъп до ключа само чрез кражба на физическото устройство. Загубата на устройството ще бъде сигнал за собственика, че ключът е откраднат. Във всеки друг случай - и това е най-важният нюанс - кражбата на ключа може да остане незабелязана и собственикът на ключа няма да разбере навреме, че е необходимо спешно да се свърже с CA и да отмени валидността на неговия сертификат .

Тук отново аналогията с банкова карта, който е инструмент за удостоверяване за достъп до банкова сметка. Докато е при собственика, той е спокоен. Ако картата е изгубена, трябва незабавно да я блокирате. В този случай задачата на нападателя не е да открадне картата, а дискретно да й направи копие, така че собственикът да не блокира достъпа. За съвременните хардуерни токени методите за клониране в момента са неизвестни.

Токени

В момента общоприетото наименование за индивидуални физически устройства, използвани за съхранение на ключове за електронен подпис, е токен. Токените могат да бъдат свързани към компютър чрез USB, Bluetooth или чрез специални устройства за четене. Повечето съвременни токени използват USB интерфейс. Но основната разлика между видовете токени не е в интерфейса на връзката. Токените могат да бъдат разделени на два вида – такива, които всъщност се използват само като хранилище на ключове, и такива, които „могат“ да извършват криптографски операции сами.

Токените от първия тип се различават от обикновените флаш устройства по същество само по това, че данните от тях могат да се четат само с помощта на специален софтуер. В противен случай това е обикновено външно хранилище за данни и ако съхраняваме таен ключ в него, тогава всеки, който получи права за достъп до устройството и знае как да разчете ключа от него, може да го открадне. Такива токени се наричат ​​софтуерни токени и на практика не дават никакви предимства в сравнение със съхраняването на ключа на компютърен диск - собственикът на ключа също не може да бъде сигурен, че знае всички места, където се съхранява секретният му ключ.

Токените от втория тип се наричат ​​хардуерни токени и основната им разлика е, че секретният ключ е невъзстановим – той никога не напуска границите на токена. За целта върху токена се поставя специален набор от софтуер, който се активира, когато токенът е свързан към компютъра. Всъщност такъв токен е независимо изчислително устройство със собствен процесор, памет и приложения, което комуникира с компютър.

Тайният ключ никога не напуска хардуерния токен, защото се генерира направо върху самия токен. За да подпишете документ, хешът на документа се зарежда в токена, изчисленията се правят директно „на борда“ на токена, като се използва секретният ключ, съхранен там, и готовият подпис се качва обратно. По този начин, знаейки местоположението на токена, ние винаги знаем местоположението на секретния ключ.

Една от основните характеристики на хардуерния токен е наборът от поддържани криптографски алгоритми. Например, ако искаме да използваме хардуерен токен за удостоверяване на домашния си компютър, всеки модерен токен ще свърши работа. И ако искаме да се удостоверим на портала за държавни услуги, тогава се нуждаем от токен, който поддържа криптографски алгоритми, сертифицирани в Русия.

По-долу са списъци с поддържани криптографски механизми за eToken и JaCarta GOST токени. За да поискате списък с механизми, беше използвана помощната програма pkcs11-tool open с параметъра „-M“ (от думата „механизъм“), който може да действа като клиентско приложение за всяка библиотека, която внедрява интерфейса PKCS # 11 в своя посока. libeToken.so и libjcPKCS11.so.1 се използват като PKCS#11 библиотеки съответно за eToken и JaCarta. Библиотеката за eToken се разпространява като част от софтуера SafeNet, библиотеката за JaCarta е достъпна за изтегляне от уебсайта на Aladdin R.D.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M Поддържани механизми: DES-MAC, keySize=(8,8), подписване, проверка на DES-MAC-GENERAL, keySize=( 8,8), подпишете, проверете DES3-MAC, keySize=(24,24), подпишете, проверете DES3-MAC-GENERAL, keySize=(24,24), подпишете, проверете AES-MAC, keySize=(16,32) ), подпишете, проверете AES-MAC-GENERAL, keySize=(16,32), подпишете, проверете RC4, keySize=(8,2048), шифровайте, декриптирайте DES-ECB, keySize=(8,8), шифровайте, декриптирайте , обвиване, разопаковане DES-CBC, keySize=(8,8), криптиране, декриптиране, обвиване, разопаковане DES-CBC-PAD, keySize=(8,8), криптиране, дешифриране, обвиване, разопаковане DES3-ECB, keySize= (24,24), hw, шифроване, дешифриране, обвиване, разопаковане DES3-CBC, keySize=(24,24), hw, шифроване, дешифриране, обвиване, разопаковане DES3-CBC-PAD, keySize=(24,24), hw, шифроване, декриптиране, обвиване, разгъване на AES-ECB, keySize=(16,32), шифроване, декриптиране, обвиване, разгъване на AES-CBC, keySize=(16,32), шифроване, декриптиране, обвиване, разгъване на AES-CBC -PAD, keySize=(16,32), криптиране, декриптиране, обвиване, разопаковане mechtype-0x1086, keySize=(16,32), криптиране, декриптиране, обвиване, разопаковане mec htype-0x1088, keySize=(16,32), криптиране, дешифриране, обвиване, разопаковане RSA-PKCS-KEY-PAIR-GEN, keySize=(1024,2048), hw, generate_key_pair RSA-PKCS, keySize=(1024,2048 ), hw, криптиране, дешифриране, знак, sign_recover, проверка, verify_recover, обвиване, разопаковане RSA-PKCS-OAEP, keySize=(1024,2048), hw, шифроване, дешифриране, обвиване, разопаковане RSA-PKCS-PSS, keySize= (1024,2048), hw, знак, проверка на SHA1-RSA-PKCS-PSS, keySize=(1024,2048), hw, знак, проверка на mechtype-0x43, keySize=(1024,2048), hw, знак, проверка на mechtype -0x44, keySize=(1024,2048), hw, знак, проверка mechtype-0x45, keySize=(1024,2048), hw, знак, проверка RSA-X-509, keySize=(1024,2048), hw, криптиране , декриптиране, знак, sign_recover, проверка, verify_recover, обвиване, разопаковане, проверка на SHA256-RSA-PKCS, keySize=(1024,2048), hw, знак, проверка на SHA384-RSA-PKCS, keySize=(1024,2048), hw , подпишете, потвърдете SHA512-RSA-PKCS, keySize=(1024 ,2048), hw, подпишете, потвърдете RC4-KEY-GEN, keySize=(8 204 8), генерирайте DES-KEY-GEN, keySize=(8,8), генерирайте DES2-KEY-GEN, keySize=(16,16), генерирайте DES3-KEY-GEN, keySize=(24,24), генерирайте AES -KEY-GEN, keySize=(16,32), генерира PBE-SHA1-RC4-128, keySize=(128,128), генерира PBE-SHA1-RC4-40, keySize=(40,40), генерира PBE-SHA1- DES3-EDE-CBC, keySize=(24,24), генериране на PBE-SHA1-DES2-EDE-CBC, keySize=(16,16), генериране на GENERIC-SECRET-KEY-GEN, keySize=(8,2048), hw, генерира PBA-SHA1-WITH-SHA1-HMAC, keySize=(160,160), hw, генерира PBE-MD5-DES-CBC, keySize=(8,8), генерира PKCS5-PBKD2, генерира MD5-HMAC-GENERAL, keySize=(8,2048), подпис, проверка на MD5-HMAC, keySize=(8,2048), подпис, проверка на SHA-1-HMAC-GENERAL, keySize=(8,2048), подпис, проверка на SHA-1-HMAC , keySize=(8,2048), знак, проверка mechtype-0x252, keySize=(8,2048), знак, проверка mechtype-0x251, keySize=(8,2048), знак, проверка mechtype-0x262, keySize=(8 ,2048), подпис, проверка mechtype-0x261, keySize=(8,2048), знак, проверка mechtype-0x272, keySize=(8,2048), знак, проверка mechtype-0x271, keySize=(8,2 048), подпишете, проверете MD5, обобщете SHA-1, обобщете SHA256, обобщете SHA384, обобщете SHA512, обобщете mechtype-0x80006001, keySize=(24,24), генерирайте $ pkcs11-tool --module /usr/local/lib64/ libjcPKCS11.so. 1 -M Поддържани механизми: GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, sign, verify GOSTR3410-WITH-GOSTR3411, hw, sign, verify mechtype-0x1204, hw, извличане GOSTR3411, hw, digest mechtype-0x1220 , генерирайте mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

Може да се види, че списъкът на поддържаните механизми за eToken е много дълъг, но не включва GOST алгоритми. Списъкът с поддържаните механизми на JaCarta включва само GOST алгоритми, но в количеството, необходимо за внедряване на EDS функционалността на хардуерен токен.

Важно е да се разбере, че модерните хардуерни токени обикновено могат да се използват и като софтуерни токени. Тоест те обикновено имат малка област от паметта, достъпна отвън, която при желание може да се използва за записване и съхраняване на външно генериран таен ключ. Технологично това няма смисъл, но всъщност този метод се използва, за съжаление, доста широко. За съжаление, защото често собственикът на токена не знае, че неговият модерен хардуерен токен, честно закупен не за символична такса, се използва като софтуер.

Примери за изключително софтуерни токени включват Rutoken S и Rutoken Lite. Като примери за хардуерни токени, които не поддържат криптографски алгоритми, сертифицирани в Русия, има устройства „eToken“; като поддържаща руска криптография - "Rutoken EDS", "JaCarta GOST".

Крипто доставчици

Софтуер, който предоставя на оператора достъп до криптографски функции – електронен подпис, криптиране, декриптиране, хеширане – се нарича криптографски доставчик, доставчик на криптографски функции. В случай на хардуерен токен, криптографският доставчик се внедрява директно върху токена, в случай на софтуерен токен или в случай на съхраняване на ключове на компютърен диск, той се внедрява като обикновено потребителско приложение.

От гледна точка на сигурността на потребителските данни, един от основните вектори на атака е насочен към крипто доставчика - именно в паметта на крипто доставчика се дешифрира секретният ключ. В случай на успешна атака, атакуващият ще може да замени кода на приложението със своя собствен и да направи копие на секретния ключ, дори ако ключът обикновено се съхранява в криптирана форма. Следователно, в случай на използване на криптография за извършване на електронен подпис, който има законова сила, държавата се стреми да защити гражданите от възможно изтичане на секретни ключове. Това се изразява във факта, че за работа с квалифициран електронен подпис е официално разрешено да се използват само доставчици на крипто, които имат съответния сертификат и следователно са преминали съответните проверки.

Доставчиците на крипто, сертифицирани в Руската федерация за EDS, включват по-специално: Rutoken EDS, JaCarta GOST, CryptoPro CSP, LISSI-CSP, VipNet CSP. Първите две са внедрени директно върху хардуерни токени, останалите са под формата на потребителски приложения. Важно е да се разбере, че когато закупуваме хардуерен токен, сертифициран в Руската федерация, ние вече придобиваме крипто доставчик, сертифициран в Руската федерация, и няма нужда - технологична и юридическа - да закупуваме друг крипто доставчик.

В допълнение към набора от поддържани алгоритми, криптографските доставчици се различават и по набор от криптографски функции - криптиране и декриптиране на документи, подписване и проверка на подпис, наличие на графичен потребителски интерфейс и т.н. Освен това, от целия този набор от функции, сертифициран криптографски доставчик трябва да изпълнява само тези, които са пряко свързани с внедряването на криптографски алгоритми. Всичко останало може да се направи от приложение на трета страна. Точно така доставчиците на крипто работят с хардуерни токени: потребителският интерфейс се реализира от приложение на трета страна, което не подлежи на задължително сертифициране. Приложението, което реализира потребителския интерфейс, комуникира с криптографския доставчик на токена чрез друг стандартен интерфейс - PKCS#11. В същото време, от гледна точка на потребителя, работата с ключове се извършва, например, директно от html браузъра Firefox. Всъщност браузърът чрез интерфейса PKCS # 11 използва специален софтуерен слой, който реализира механизми за достъп до конкретен хардуерен токен.

В допълнение към термина "криптографски доставчик" има още един термин, който е близък по значение - "средства за криптографска защита на информацията" (CIPF). Няма ясно разграничение между тези две понятия. Първият термин е по-малко официален, вторият се използва по-често във връзка със сертифицирани технически решения. Тъй като този документ описва основно технологични, а не формални аспекти, ще използваме по-често термина „криптопровайдер“.

Внедряване на механизми

Алгоритми за електронен подпис

Понастоящем в Руската федерация за квалифициран електронен подпис е разрешено официално да се използват само два алгоритъма за подпис и два алгоритъма за хеширане. До края на 2017 г. е разрешено използването на GOST R 34.10-2001 заедно с алгоритъма за хеширане на GOST R 34.11-94. От началото на 2018 г. е разрешено да се използват само GOST R 34.10-2012 и хешове в съответствие с GOST R 34.11-2012. В ситуации, в които не се изисква задължително използване на GOST алгоритми, могат да се използват всички налични алгоритми.

Например, сега повечето уебсайтове, достъпни чрез HTTP протокола, не знаят как да използват GOST алгоритми за взаимно удостоверяване на клиента и сървъра. В случай на взаимодействие с един от тези сайтове, клиентската страна също ще трябва да приложи „чуждестранни“ алгоритми. Но, например, ако искате да използвате хардуерен токен като хранилище на ключове за удостоверяване на уебсайта на държавните услуги, ще трябва да изберете токен с поддръжка на EDS според GOST.

Необходимостта от използване на руски алгоритми при взаимодействие с държавни агенции изобщо не се дължи на желанието да се ограничат гражданите в техния избор. Причината е, че държавата, инвестирала в разработването на тези алгоритми, носи отговорност за тяхната криптографска сила и липсата на недекларирани функции в тях. Всички криптографски алгоритми, стандартизирани в Руската федерация, многократно са преминали независим одит и убедително са доказали своята стойност. Същото може да се каже и за много други общи криптографски алгоритми. Но, за съжаление, липсата на недекларирани възможности в тях не може да се докаже със същата лекота. Съвсем ясно е, че от гледна точка на държавата е неразумно да се използват ненадеждни средства, например за обработка на лични данни на граждани.

Интерфейси, формати и протоколи

За осигуряване на съвместимост при работа с електронен подпис са разработени редица международни стандарти относно съхранението на данни и предоставянето на достъп до тях. Основните стандарти включват:

  • PC/SC - интерфейс от ниско ниво за достъп до криптографски устройства, включително софтуерни и хардуерни токени;
  • PKCS#11 - интерфейс от високо ниво за взаимодействие с хардуерни криптографски модули, може да се разглежда като унифициран интерфейс за достъп до криптографски доставчици;
  • PKCS#15 - контейнерен формат с ключове за електронен подпис, предназначен за съхранение на физическо устройство;
  • PKCS#12, PEM - контейнерни формати с ключове за електронен подпис, предназначени за съхранение съответно във файлове, двоични и текстови;
  • PKCS#10 - формат на документ - заявка за подписване, изпратена от клиент до CA за получаване на подписан сертификат.

Важно е да се разбере, че стандарти като PKCS#11 или PKCS#15 първоначално са разработени, без да се вземат предвид спецификите на криптовалутите, сертифицирани в Руската федерация. Следователно, за да се приложи пълноценна поддръжка за вътрешна криптография, стандартите трябваше и все още трябва да бъдат финализирани. Процесът на приемане на промени в стандартите е дълъг, поради което до окончателното приемане на финализираните стандарти се появиха техните изпълнения, които бяха несъвместими помежду си. По-специално, това се отнася за доставчици на крипто, сертифицирани в Руската федерация. И така, сега всички сертифицирани доставчици на крипто имат несъвместими реализации на контейнери за съхраняване на ключове в токен. Що се отнася до стандартите за обмен на данни - PKCS # 10, PKCS # 12, PEM - техните реализации, за щастие, обикновено са съвместими помежду си. Освен това обикновено няма несъответствия в тълкуването на стандарта PC / SC.

Въпросите за финализиране на стандарти, разработване на препоръки, осигуряване на съвместимост в областта на EDS в Руската федерация в момента се обработват от специална организация - Техническия комитет по стандартизация "Криптографска защита на информацията" (TK 26), който включва експерти, представители на правителствени агенции, разработчици на криптографски доставчици и други заинтересовани лица. Може да се спори за ефективността на работата на комисията, но дори самото наличие на такава платформа е изключително важно.

Софтуерна част

Софтуерният стек за работа с електронен подпис се състои от следните компоненти:

  • внедряване на интерфейс за достъп на ниско ниво до контейнери за съхранение с ключове - например PC/SC интерфейс за достъп до физически устройства - токени;
  • модул, който имплементира интерфейса PKCS#11 за взаимодействие с криптографски доставчик - например, имплементиран на хардуерен токен;
  • криптографски доставчик, който внедрява съответните криптографски алгоритми и извършва действия с тях – например електронен подпис или криптиране на данни;
  • потребителско приложение, което взаимодейства с другата - по отношение на криптографския доставчик - страна с модула PKCS # 11 и изпълнява операции като електронен подпис или удостоверяване от името на потребителя.

Пример за стек:

  • Приложението за команден ред cryptcp от софтуера CryptoPro CSP взаимодейства с библиотеката libcppksc11.so чрез интерфейса PKCS#11 и предоставя възможност за подписване на документи с тайния ключ на потребителя; в същото време функциите на крипто доставчика са напълно внедрени в компонентите на софтуера CryptoPro CSP, крипто доставчикът на хардуерния токен не участва.

Друг пример:

  • отвореният софтуер pcsc-lite реализира PC/SC интерфейс за взаимодействие с хардуерния токен Rutoken EDS;
  • библиотеката libcppksc11.so от софтуера CryptoPro CSP осигурява взаимодействие с контейнера, хостван на токена, който съхранява частния ключ и сертификат на потребителя;
  • приложението „CryptoPro EDS Browser plugin“, което работи като част от html браузъра Firefox, взаимодейства с библиотеката libcppksc11.so чрез интерфейса PKCS#11 и предоставя възможност за подписване на документи в интерфейса на браузъра на електронни уебсайтове. търговски етажи; в същото време функциите на крипто доставчика са напълно внедрени в компонентите на софтуера CryptoPro CSP, крипто доставчикът на хардуерния токен не участва.

Трети пример:

  • отвореният софтуер pcsc-lite реализира PC/SC интерфейс за взаимодействие с хардуерния токен Rutoken EDS;
  • библиотеката librtpksc11.so, произведена от Aktiv, осигурява взаимодействие с криптографския доставчик на токена;
  • криптографският доставчик на токена изпълнява функциите за подписване на предадените към него данни със секретен ключ; секретният ключ не напуска границите на токена;
  • приложението Rutoken Plugin, работещо като част от html браузъра Firefox, взаимодейства с библиотеката librtpksc11.so чрез интерфейса PKCS # 11 и предоставя възможност за подписване на документи в интерфейса на браузъра на съвместими сайтове; в същото време функциите на криптографския доставчик са напълно внедрени на хардуерен токен.

Изборът на конкретна реализация на стека в момента се определя преди всичко от три фактора - предвидения обхват на EDS, нивото на технически познания на потребителя и готовността на сертифициращия център да работи с искане за подписване на сертификат.

В допълнение към набора от потребителски софтуер, изброен по-горе, има още две приложения, които трябва да бъдат разгледани. Първият е софтуерът, който обслужва сертификационния център. Второто е софтуерът, с който искаме да сме съвместими. Например уебсайтът на държавните служби. Или софтуер за подписване на електронни документи.

Ако сертифициращият орган, от който планираме да получим сертификат, не е готов да работи със заявки за подписване във формат PKCS # 10 и може да работи само със софтуерни токени (т.е. възприема всеки токен като софтуер), нямаме избор. По правило в този случай CA софтуерът ще генерира двойка ключове за нас, ще я запише в токена, ще генерира незабавно заявка за подпис въз основа на публичния ключ и нашите лични данни, ще я подпише и ще съхрани сертификата на токена . Сертификатът и ключът ще бъдат в контейнер със затворен формат, известен само на разработчика на CA софтуер. Съответно, за достъп до контейнера с ключове, ще трябва да закупите криптографски доставчик от същия разработчик. И обхватът на EDS ще бъде ограничен от възможностите на софтуера на един конкретен разработчик. В този случай няма смисъл да купувате хардуерен токен - можете да минете със софтуерен. В този случай токенът определено ще трябва да бъде пренесен в CA.

Ако сертифициращият орган, където планираме да получим сертификат, е готов да работи със заявки за подписване във формат PKCS # 10, тогава за нас няма значение какъв софтуер се използва в този CA. Ще можем да използваме криптографския доставчик, който е съвместим с нашите целеви приложения. Например с електронни платформи за търговия или уебсайта на държавните служби. В този случай не е необходимо да носите токена в CA, достатъчно е да генерирате заявка за подпис и да я представите там заедно с вашите хартиени документи; вземете сертификат и го запазете сами на токена с помощта на избрания крипто доставчик.

За съжаление, много малко сертифициращи органи в момента (края на 2016 г.) са готови да работят със заявка за подписване. Тази ситуация отчасти се дължи на липсата на техническо обучениепотребители, които не могат да гарантират, че заявката за подпис е правилно изпълнена - с всички необходими атрибути и техните стойности. Това ръководство има за цел да реши този проблем.

Хардуер

Сред представените на руски пазартокените включват следното:

Хардуерни носители с поддръжка на руска криптография: Rutoken EDS, JaСarta GOST, MS_KEY K.

Нека разгледаме като пример списъците с поддържани криптографски механизми на хардуера Rutoken EDS и софтуера Rutoken_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Поддържани механизми: RSA-PKCS-KEY-PAIR-GEN, keySize=(512,2048), hw, generate_key_pair RSA-PKCS, keySize=( 512,2048), hw, шифроване, декриптиране, подписване, проверка на RSA-PKCS-OAEP, keySize=(512,2048), hw, шифроване, дешифриране MD5, дайджест SHA-1, дайджест GOSTR3410-KEY-PAIR-GEN, hw , generate_key_pair GOSTR3410, hw, подпис, проверка mechtype-0x1204, hw, извличане на GOSTR3411, hw, обобщение GOSTR3410-WITH-GOSTR3411, hw, обобщение, знак mechtype-0x1224, hw, обвиване, разгъване mechtype-0x1221, hw, криптиране, дешифриране mechtype-0x1222, hw, криптиране, дешифриране mechtype-0x1220, hw, генериране на mechtype-0x1223, hw, знак, проверка $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Поддържани механизми:

Както можете да видите, списъците с поддържани криптографски механизми Rutoken Lite са празни, за разлика от Rutoken EDS, който включва GOST и RSA алгоритми.

Хардуерните токени без поддръжка за руска криптография, както бе споменато по-горе, включват по-специално JaCarta PKI и eToken.

Предвид сравнително ниските цени на хардуерните токени с поддръжка на руска криптография, можем уверено да препоръчаме използването им. В допълнение към очевидното предимство под формата на невъзстановим таен ключ, хардуерният токен включва и сертифициран доставчик на крипто. Тоест, възможно е да организирате работата с токена по такъв начин, че да не е необходимо да купувате допълнително скъп софтуер.

От последните разработки бих искал да отбележа Rutoken EDS 2.0 с поддръжка на стандарта GOST R 34.10-2012.

Приложение

Потребителски инструменти

Отворете Инструменти

Понастоящем софтуерът с отворен код ви позволява да внедрите почти пълен софтуерен стек за работа с EDS.

PCSC олекотен

PC/SC внедряването, разработено в рамките на проекта PCSC lite, е еталон за семейството на Linux OS. Той е включен във всеки от вариантите на софтуерния стек, разглеждан в този документ за работа с EDS. В бъдеще, ако конкретна опция за внедряване не е посочена, ще я считаме за активирана по подразбиране.

OpenSC

Библиотеката, която имплементира интерфейса PKCS#11, както и набор от приложни инструменти, които използват неговата функционалност, е разработена като част от проекта OpenSC. Инструментариумът поддържа много хардуерни токени, включително Rutoken EDS, чиято поддръжка е добавена от специалистите на компанията Aktiv, която разработва токени от семейството Rutoken.

С помощта на помощните програми на OpenSC можете да извършвате по-специално следните действия върху хардуерен токен:

  • инициализиране на токена - нулиране на настройките до първоначалното състояние;
  • задаване на администраторски и потребителски PIN (ако се поддържа);
  • генерирайте двойка ключове (ако се поддържа от библиотеката PKCS#11);
  • импортирайте сертификат, подписан от сертифициращ орган върху токена.

Библиотеката PKCS#11 от пакета OpenSC ви позволява да извършвате пълен набор от операции с електронен подпис върху поддържани токени. Поддържаните токени включват също Rutoken EDS.

Тук е важно да се разбере, че за Rutoken EDS има две различни вариантиподдръжка от софтуер, който не е съвместим помежду си във формата за съхраняване на ключове на токена. Когато използваме библиотеката PKCS # 11 от OpenSC, можем да използваме отворения софтуерен стек, а когато използваме безплатната разпределена затворена библиотека, произведена от Aktiv, можем да използваме затворения стек Aktiva.

OpenSSL

За да се използват пълноценно възможностите на EDS, в допълнение към самата библиотека PKCS # 11 трябва да бъдат внедрени потребителски приложения, които предоставят на оператора достъп до функциите на библиотеката и възможностите на токените. Основен пример за такава реализация е софтуерът с отворен код от проекта OpenSSL. Той поддържа следните функции по-специално:

  • криптиране на данни;
  • дешифриране на данни;
  • подпис на документ;
  • проверка на подписа;
  • генериране на заявка за подписване на сертификат;
  • внос на сертификати;
  • износ на сертификат.

В допълнение, използвайки OpenSSL, можете да внедрите функционалността на пълноценен сертифициращ орган, включително:

  • издаване на клиентски сертификати чрез подписване на заявки за подписване във формат PKCS#10;
  • отнемане на клиентски сертификати;
  • регистрация на издадени и прекратени удостоверения.

Единственият недостатък на OpenSSL в момента, който все още не позволява внедряването на пълнофункционална версия на софтуерния стек EDS, базиран на софтуер с отворен код, е липсата на отворен модул за взаимодействие с библиотеки PKCS # 11 с поддръжка на GOST алгоритми. Има затворена реализация на такъв модул, направена от Aktiv, но тя не е включена в основната дистрибуция на OpenSSL и следователно с пускането на нови версии на OpenSSL съвместимостта периодично се нарушава. Отвореното изпълнение на този модул все още не поддържа GOST алгоритми.

Firefox

В допълнение към OpenSSL, добре познатият html браузър Firefox може също да взаимодейства с библиотеките PKCS # 11. За да свържете библиотеката PKCS # 11, трябва да отидете в менюто за управление на настройките „Предпочитания“, след това да изберете „Разширени“ във вертикалния списък вляво, да изберете „Сертификати“ в хоризонталния списък, да щракнете върху бутона „Устройства за сигурност“ , в появилия се диалогов прозорец щракнете върху бутона „Зареждане“. Ще се появи друг прозорец с опция за избор на пътя до файла с библиотеката PKCS#11 и опция за въвеждане на локалното име за тази конкретна библиотека. Можете да заредите няколко различни PKCS#11 модула по този начин за различни видове физически и виртуални устройства.

За съжаление, функционалността на Firefox все още не е достатъчна за подписване на документи в интерфейса на уебсайта. Следователно, за пълноценен отворен софтуерен стек EDS с поддръжка на GOST, все още няма достатъчно плъгин (плъгин), който ви позволява да осъществявате достъп до обекти на токена от софтуера на сайта. Надяваме се, че такъв плъгин ще бъде написан в близко бъдеще. Или отворен.

КриптоПро

Във версии на CryptoPro CSP до и включително 4.0, ръчното управление на локалните кешове се използва за съхраняване на потребителски сертификати и CA сертификати. За пълноценна работа с потребителски сертификат е необходимо неговото копие да бъде в един локален кеш, а пълната верига от CA сертификати до и включително основния - в друг. Технологично тази функция на CryptoPro, строго погледнато, не е напълно оправдана: има смисъл да се проверява веригата по време на удостоверяване; действителният факт на валидност на удостоверението не засяга възможността за подписване. Особено ако това е наш собствен сертификат и знаем откъде идва. В пресните по време на писане на бета версиите на CryptoPro CSP, според разработчиците, е въведено автоматично зареждане на веригата на CA сертификати. Но гарантирането, че само този, който се използва в момента, е в локалния кеш на потребителските сертификати, изглежда все още трябва да се наблюдава ръчно.

Разработчиците на трети страни правят опити да напишат графични интерфейси за CryptoPro CSP, улеснявайки рутинните потребителски операции. Пример за такава помощна програма е rosa-crypto-tool, която автоматизира подписването и криптирането на документи. Пакет в ALT дистрибуции.

CryptoPro CA

Софтуерът Lissi SOFT се характеризира със стриктно спазване на стандартите и техническите спецификации. Крипто доставчиците, включително уникалните, са проектирани като библиотеки PKCS#11. Според разработчиците те се вписват добре в софтуера с отворен код, който също е фокусиран върху поддържането на стандарти. Например с html браузъри и помощни програми от комплекта OpenSSL.

По отношение на организирането на достъпа до сайтове за обществени услуги интерес представляват и продуктите на Lissy SOFT. На първо място - съвместимост с "IFCPlugin" - плъгин за браузър, който внедрява EDS механизми на портала за държавни услуги. Второ, способността на софтуера на сертифициращия орган да работи със заявки за подписване на сертификати във формат PKCS#10.

Браузъри

Понякога за достъп до сайтове, където планираме да използваме механизми за електронен подпис, трябва да използваме други технологии, които използват руска криптография. Например алгоритмите на GOST могат да се използват за организиране на криптиран канал за предаване на данни. В този случай е необходима поддръжка на съответните алгоритми в браузъра. За съжаление, официалните версии на Firefox и Chromium все още не поддържат напълно руската криптография. Следователно трябва да използвате алтернативни възли. Такива сборки са например в арсенала на крипто-средствата на компаниите "CryptoPro" и "Lissy SOFT", както и в дистрибуциите на Alt.

сайтове

Сред сайтовете, които изискват използването на технологии за електронен подпис, ние се интересуваме предимно от сайтове, които предоставят обществени услуги, както и електронни платформи за търговия (ETP). За съжаление, някои ETP все още не поддържат работа с ОС от регистъра на руския софтуер. Но ситуацията постепенно се променя към по-добро.

Използването на EDS за уеб сайтове обикновено се свежда до удостоверяване и подписване на документи, генерирани в интерфейса на сайта. По принцип удостоверяването изглежда по същия начин като подписа на всеки друг документ: сайтът, на който клиентът иска да удостовери, генерира поредица от знаци, които изпраща на клиента. Клиентът изпраща обратно подписа на тази последователност, направен с неговия частен ключ и своя сертификат (сертификатът е малко по-ранен). Сайтът взема публичния ключ от клиентския сертификат и проверява подписа на оригиналната последователност. Същото важи и за подписването на документи. Тук вместо произволна последователност се появява самият документ.

обществени услуги

В резултат на проучването се оказа, че към 14 декември 2016 г. повечето от федералните платформи за търговия - "", "RTS-tender" и "Sberbank-AST" са готови за използване на работни места, работещи под операционната система от семейството на Linux . Останалите два сайта все още дори не предоставят възможност за влизане с клиентски сертификат. Дали техните разработчици планират някакви мерки за осигуряване на съвместимост, за съжаление, все още не е установено.

В същото време в официалните инструкции на всички сайтове, с изключение на Единната електронна платформа за търговия, операционната система Windows е посочена като единствената поддържана. Официални сервизни отговори техническа поддръжкапотвърдете тази информация. Инструкциите на уебсайта на Обединената електронна платформа за търговия описват настройките на браузъра, без да посочват конкретна операционна система.

В обобщен вид резултатите от изследването са дадени в таблицата:

Електронен пазар Възможност за влизане с потребителски сертификат Възможност за подписване на документ в интерфейса на платформата Документация за работа със сайта под ОС от Регистъра
Сбербанк - Автоматизирана система за търговия да да Не
Единна платформа за електронна търговия да да да

За ETP, които осигуряват съвместимост с Linux, единственият поддържан крипто инструмент в момента е плъгинът Cades, който може да използва CryptoPro CSP само като крипто доставчик. По този начин добрата новина е, че е много лесно да получите токен за достъп до електронни платформи за търговия - повечето CA ги издават. Лоши новини - токенът ще бъде базиран на софтуер и няма да е съвместим с уебсайта на държавните служби.

За други платформи за търговия единственият начин за достъп до функционалността на EDS е компонентът на Windows OS, наречен CAPICOM. Специалистите на Etersoft извършиха изследователска работа, в резултат на която беше изяснена теоретичната възможност за стартиране на CAPICOM в средата на Wine.

Други сайтове

Освен изброените сайтове, които използват EDS директно – за влизане в сайта и подписване на документи, генерирани в интерфейса на сайта, има редица сайтове, които предоставят възможност за изтегляне на документи, предварително подписани с квалифициран електронен подпис. Пример е сайтът на Главния радиочестотен център. Достъпът до сайта се осъществява чрез логин и парола, а документите се подготвят и подписват предварително – в потребителския интерфейс на ОС. Следователно, за да работите с такива сайтове, е необходима само функционалност за подписване на локални документи. Тоест в този случай практически няма ограничения за избора на крипто доставчик.

Пример за готово решение

За съжаление, в момента авторите на този документ не знаят как да използват един и същ токен едновременно на уебсайта на държавните услуги и на електронни платформи за търговия. Следователно ще трябва да направите два токена с две двойки ключове и съответно два сертификата. Не е законово забранено, технически е осъществимо. Финансово също е доста реалистично: единият токен ще бъде например хардуерен Rutoken EDS, другият ще бъде някакъв стар модел eToken, който сега може да се намери срещу номинална такса.

Достъп до уебсайта на държавните служби

За достъп до държавните услуги вземете Rutoken EDS и изпълнете следните стъпки:

  1. изтеглете софтуера на плъгина Rutoken от страницата на връзката;
  2. инсталирайте приставката Rutoken - копирайте файловете на приставката (npCryptoPlugin.so и librtpkcs11ecp.so) в ~/.mozilla/plugins/ ;
  3. отидете на сайта със софтуера на Центъра за регистрация и следвайте инструкциите за извършване на следните действия - инициализиране на токена, генериране на двойка ключове, генериране и запазване на локален файл със заявка за подпис във формат PKCS # 10;
  4. ще се свържем с КО, който е готов да ни издаде сертификат при поискване за подпис, ще получим сертификат под формата на файл;
  5. в интерфейса "Регистрационен център" запишете сертификата от получения файл върху токена;
  6. изтеглете пакета във формат “deb” от линка - файла IFCPlugin-x86_64.deb ;
  7. с помощта на софтуера "Midnight Commander" (команда mc) "отидете" в пакетния файл като в директория;
  8. копирайте съдържанието на директорията СЪДЪРЖАНИЕ/usr/lib/mozilla/pluginsкъм локалната директория ~/.mozilla/plugins;
  9. в браузъра Firefox на уебсайта на държавните служби ще последваме последователно връзките „Вход“ и „Вход с помощта на електронни средства“.

Основният проблем при прилагането на тази инструкция е да се намери сертифициращ орган, който е готов да работи с искане за подпис.

Достъп до електронни платформи за търговия

За достъп до сайтовете на електронни платформи за търговия, които поддържат работа в Linux, изпълнете следните стъпки:

  1. с всеки токен, официално продаден в Руската федерация, ще се свържем с всеки сертификационен център, който използва CryptoPro CA, и ще получим потребителския сертификат и секретния ключ, съхранени на токена в контейнер във формата, поддържан от софтуера CryptoPro;
  2. в съответствие със инструкцияинсталирайте софтуера "CryptoPro CSP" и "Cades plugin" за браузъра Chromium;
  3. използвайки браузъра Chromium, ще отидем на сайтовете на електронни платформи за търговия и ще започнем да работим с тях съгласно официалните инструкции.

Възможността за подписване на документи под формата на файлове ще бъде достъпна чрез помощните програми на конзолата на CryptoPro и чрез обвиващи приложения на трети страни като вече споменатия rosa-crypto-tool.