written on Friday, January 23, 2015
В українському державному IT-секторі є така хуйова штука, як цифрова повинність. Суть в тому, що держава колись вирішила: для здачі електронної звітності та взагалі для ідентифікації людини в інтернеті потрібен цифровий підпис. І тепер вимагає його як від тих, хто звітність здає (підписувати), так і від постачальників всяких сайтів-шмайтів, щоб там ЕЦП підтримувалося. Здавалося б — тріумф криптомафії, зручності та всього такого. Ну, це якщо ви кончений технар-програміст і не слідкуєте за руками.
Найобка перша в тому, що вважається ЕЦП. ЕЦП — це поняття не технічне, а юридичне. Більше того, з цими нашими Європами, потрібен ще й кваліфікований ЕЦП. Тобто, наприклад, GPG — це не ЕЦП, персональний сертифікат ключа, де особистість перевірена якимось Verisign — теж ні. Сертифікат сайту — взагалі ніяк не ЕЦП, бо засвідчує об'єкт (сайт), а не суб'єкта, якому він належить (юрика чи фізика). Сертифікат сайту, де Verisign все ж перевірив суб'єкта, і браузер пише зеленим "Twitter Inc" — все одно не ЕЦП. Ну тобто ЕЦП — це не та вся хуйня, яку нормальні люди юзають для корисної справи, а довідка, яка потрібна чиновнику.
Щоб отримати ЕЦП, треба спочатку отримати сертифікат у спеціального українського CA яких звісно є кілька, включаючи державний, який видає сертифікати безкоштовно.
Сертифікат — звичайний X509v3, такий самий, що використовується в HTTPS і TLS взагалі. Ну тобто ні. Там звісно X509v3, але в Subject Name записане ваше ім'я українською кирилицею, як у паспорті, а десь дуже далеко в надрах екстеншенів ще й ІПН (він же ДРФО). Ну і звісно такий сертифікат не можна імпортувати в кейчейн браузера чи скормити openssl, бо там використовується не богомерзкий і дірявий RSA чи там ECDSA з кривими SHA-1 і MD-5, а національне надбання — алгоритм ДСТУ 4145, найкращий алгоритм, швидкий і безпечний ЕЦП у світі (за версією Державної Служби СпецЗв'язку).
Окей, всі майстри PHP втекли, залишилися звиклі до всякої хуйні програмісти, які й не таке бачили. Ну ще один несумісний шматок говна, зараз ми алгоритм реалізуємо, сертифікат розпарсимо, нахуяримо патч на OpenSSL, щоб все це проінтегрувати і буде щастя. Ви не перший такий розумний — все вже зібрано і лежить у PPA.
Отже, у нас був патч на SSL, збірка під убунту, репо на гітхабі, два пакети з гостом і f2m під ноду, демон на OpenSSL+re, реалізація підписувача і перевіряча на пайтоні, розбиралка сертифікатів і форматів для клієнтського жаваскрипта, конвертер ключів, десять багів в ASN.1 парсері і шлюз аутентифікації, який експортує перевірку юзерів через OAuth2. Не те щоб це все комусь допомогло, але якщо ти програміст і бачиш ненаписаний шматок інфраструктури, то буває важко зупинитися.
Найобка номер два — у форматі ключів. Сертифікат у нас звичайний (ну окей, плюс свій алгоритм), а де ж приватний ключ? Ну от це от, яке "----BEGIN PRIVATE KEY----" і багато літерок в base64?
Ключі лежать у зашифрованому контейнері, на контейнер немає спеки. Чисто теоретично, з 2015го року все має бути PBES2/PBKDB, але я цього року в Україні ще не був і не знаю ситуації на місцях. Окей, ви берете іду проу, jda чи кому що зручніше, самі пишете спеку на контейнер, робите конвертер ключів у стандартний формат, який розуміє OpenSSL.
Здавалося б — беремо і підписуємо. Але не так швидко.
Тривіальщину з форматом підпису, двома ключами в одному контейнері і всією цією порнографією з LE/BE я залишу для окремого технічного поста. Якщо коротко — PKCS#7 (aka CMS) з зазначенням своїх алгоритмів (як і в сертифікаті X509), плюс враппер навколо нього з вказівкою, що АААА ВСЕРЕДИНІ ПІДПИСАНИЙ PKCS#7!!!!!! і OpenSSL звісно це не прожує. Спеціальна бібліотека jk може це прожувати і згенерувати (але не перевіряє сам сертифікат), спеціальна бібліотека zozol на пайтоні може розпарсити і витягнути все цікаве, але це по великому рахунку нікого не їбе.
Наступна найобка майже ідентична першій — ЕЦП це не те, чим ви користуєтеся чи можете самі згенерувати. ЕЦП — це спеціальна юридична штука, яка виникає в той момент, коли софт схвалений спецзв'язком генерує пережований PKCS#7 з врапперами. Якщо його генерує не спеціально схвалений софт, то це не ЕЦП, а набір байтиків. Документація, сертифікація, статус постачальника довірених послуг, висновок про те, що засіб захисту інформації визнаний надійним. Ну або купувати за кілобакс + щомісячні відрахування бібліотеку, яка вже це все пройшла.
Окей, скажете ви — я програміст, мене ці крючкотворства не їбуть, давайте підпишемо, а доводити будемо якщо що в суді. По байтиках же не видно, хто їх згенерував.
Наступна найобка в тому, що такої штуки, як електронний підписаний документ насправді немає, окрім як в податковій, реєстраційній службі і спеціальній фігні для ритейлерів. Наприклад, можна взяти XML-ку, підписати через dstucrypt/agent, послати на пошту податкової і там її прожує робот. Ну або можна взяти RTF документ, який присилає реєстраційна служба, закинути в eusign.org/doc і подивитися, що так підписано. При цьому формати у першого і другого будуть відрізнятися.
Яким чином укласти контракт, підписати акт виконаних робіт і як потім доводити, що вони дійсно підписані — незрозуміло. Одне з шикарних пояснень процесу — перед тим, як тягнути когось за жопу в суд з електронним контрактом, треба цей електронний контракт віднести в CA, щоб він дав паперовий висновок, що так підписано, реальне настоящий ЕЦП.