Пример за практическо приложение на механизма за електронен цифров подпис
Сайт на Delphi: ежедневни Delphi-новини, документация, статии, преглед, интервю, компютърен хумор.
Пример за практическо приложение на механизма за електронен цифров подпис
За какво е
Изправен пред проблема с осигуряването на контрол върху автентичността на документите, съхранявани в базата данни, дълго време търсех начин да го реша. Намерената информация е малко полезна за начинаещи, защото има пристрастия или в теорията / математиката на алгоритмите за асиметрично криптиране, или в юриспруденцията (да, точно тези закони за цифровите подписи). Ще направя всичко възможно да поправя ситуацията.
Примерът е реализиран в среда Delphi 6, СУБД Interbase/Firebird, компоненти за достъп InterBase Express (IBX), криптиране - LockBox. Хешът се получава с помощта на MD5 алгоритъм, RSA криптиране.
Базата данни съдържа таблица с документи DOCUMENTS, чиято автентичност трябва да контролираме, таблица DOCUMENT_SIGNS - подписи на документи от определени потребители от таблицата USERS.
Оперативна логика
На потребителя се генерират/присвояват два ключа - отворен (публичен) и затворен (частен). Първият е достъпен за всички (ще се използва за проверка на подписа и документа), а вторият само за потребителя. За да подпише документ, неговият хеш се изчислява (шифроването на цял документ от половин мегабайт е доста ресурсоемко :), този хеш се криптира с частен ключ (за да стане това - т.е. само собственикът на ключа и никой друг не може да формира самия подпис) и се въвежда в таблицата DOCUMENT_SIGNS, обвързвайки се с конкретен потребител и документ. Ако някой иска да провери дали документът е подписан от потребителя или потребителят иска да контролира неизменността на документа - той дешифрира подписа с публичния ключ и го сравнява с хеша на документа - ако тесъответства - документът е автентичен
Хешът на документа се изчислява на сървъра (за да не се карат данни напразно) с помощта на UDF. За това са реализирани две функции - хеширане на петна (md5_blob) и хеширане на низ (md5_string). Ако документът се съхранява като петно, тогава всичко е просто, но ако се съхранява като набор от полета, тогава можете да прочетете хеша от низ, състоящ се от свързани полета ( изберете md5_string(d.doc_f2d.doc_f1) от документи d). В последния случай запомнете: полетата, на базата на които се изчислява хешът, не трябва да са nullable - null + стойност = null, сумата от дължините на всички полета не е повече от максималната дължина на низа на СУБД.
Дешифрирането на подписа се извършва в клиентското приложение, но никой не си прави труда да ги прехвърли в udf.
Хеширане - в идеалния случай необратима трансформация, която позволява на данни с променлива дължина да връщат недвусмислено съответстващи данни с фиксиран размер (дайджест, хеш), обикновено 128 бита.
Генериране на двойки ключове, присвояване на публичен ключ на потребител, запазване на частен ключ във файл. Размерът на ключа е важен, за клиентското приложение той е "вграден" в кода (1024).
Подписване на избрания документ от конкретен потребител, проверка на подписа, премахване на подписа от документа.
Заключение
Приложения
Изходни текстове + база данни | dig_sign.zip (51.1K) |
кутия за заключване | tplockbox_2_07.zip (315K) |