Java за цифрово подписване на документи в уеб


Уеб приложение за верификация на цифровия подпис и използвания сертификат



страница9/14
Дата14.08.2018
Размер2.83 Mb.
#78668
1   ...   6   7   8   9   10   11   12   13   14

2.3.Уеб приложение за верификация на цифровия подпис и използвания сертификат


Освен аплетът, който подписва изпращаните от потребителя файлове, нашата уеб-базирана информационна система трябва да реализира и функционалност за посрещане на тези подписани файлове заедно с проверка на получената сигнатура. Необходимо е още получените клиентски сертифи­кати и сертификационни вериги също да бъдат проверявани, за да е ясно кой всъщност подписва получените файлове. Да разгледаме проблемите, свързани с тези проверки.

2.3.1.Система за верификация на цифровия подпис


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

2.3.2.Система за верификация на сертификати


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

Верификация на цифрови сертификати


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

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


Проверка на сертификационната верига


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

За целта може да се използват средствата на Java Certification Path API и алгоритъмът PKIX, който е реализиран стандартно в JDK 1.4. Необходимо е единствено приложението да поддържа множество от Root-сертификати на сертификационни органи от първо ниво, на които безусловно вярва (trusted CA root certificates).


Директна верификация на сертификат


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

Вместо да се изгражда и верифицира сертификационната верига на даден сертификат, може да се проверява само дали той е подписан директно от сертификат, на който имаме доверие. Системата може да поддържа съвкупност от сертификати, на които има доверие (trusted certificates) и при проверка на даден сертификат да търси серти­фикат от списъка на доверените сертификати, който се явява негов директен издател. Ако се намери такъв доверен сертификат, проверя­ваният сертификат, може да се счита за валиден, ако не е с изтекъл срок на годност.

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

2.3.3.Проектиране на уеб приложението


Уеб приложението трябва да е Java-базирано (за да можем да използваме стандартните криптографски възможности на Java платформата, които вече разгледахме) и трябва да се грижи за:

  • Получаване на изпратения от уеб браузъра документ (файл) от получената уеб форма.

  • Получаване и декодиране на цифровия подпис, получен с уеб формата.

  • Получаване и декодиране на получения с уеб формата цифров серти­фикат, използван за подписването на получения документ.

  • Верификация на цифровия подпис на получения документ по публич­ния ключ, извлечен от получения сертификат.

  • Верификация на получения цифров сертификат. Трябва да се поддържа директна верификация и верификация на сертификацион­ната верига (когато е налична). За целта трябва да се поддържат множество от доверени Root-сертификати и множество от сертификати за директна проверка.

Резултатите от всички описани проверки трябва да се визуализират по подходящ начин.



Национална академия по разработка на софтуер

Лекторите
» Светлин Наков е преподавател по съвременни софтуерни технологии в СУ “Св. Климент Охридски”.

Той е автор на десетки на­учни и технически публи­ка­ции и ня­колко книги, свър­­зани с раз­работката на соф­ту­ер, заради което е търсен лектор и консултант.

През 2004 г. получава наг­ра­дата "Джон Атанасов" от прези­дента на България Ге­орги Пър­ва­нов за приноса му към разви­тието на инфор­ма­ци­он­ните технологии и ин­формаци­он­ното общество.
» Мартин Кулов е изпълнителен директор във фирма “Код Атест”, където раз­работва проекти за пови­ша­ване качеството на соф­ту­ер­ните продукти в Бъл­гария чрез автоматизация на про­цесите и внедряване на сис­теми за управление на ка­чеството.

Мартин е опитен лектор и сертифициран от Майкрософт разработчик по програмите MCSD и MCSD.NET.


» Други инструк­тори с опит като преподаватели и програмисти.

Академията
» Национална академия по раз­ра­ботка на софтуер (НАРС) е център за професионално обу­чение на соф­ту­ерни специалисти.
» НАРС провежда задълбочени кур­сове по разработка на софтуер и съв­ременни софтуерни тех­нологии.
» Предлагани специалности:

.NET Enterprise Developer

Java Enterprise Developer
» Качествено обу­чение с много практически упраж­нения
» Завършвате само за 3 месеца.
» Гарантирана работа след успеш­но завършване!
» Професионална сертификация!
» БЕЗПЛАТНО!

Учите безплатно, плащате след като завършите и започнете работа.

Стипендии от софтуерни фирми.


http://academy.devbg.org


Каталог: books -> signatures
books -> В обятията на шамбала
books -> Книга се посвещава с благодарност на децата ми. Майка ми и жена ми ме научиха да бъда мъж
books -> Николай Слатински “Надеждата като лабиринт” София, Издателство “виденов & син”, 1993 год
books -> София, Издателство “Българска книжница”, 2004 год. Рецензенти доц д. ик н. Димитър Йончев, проф д-р Нина Дюлгерова Научен редактор проф д-р Петър Иванов
books -> Николай Слатински “Измерения на сигурността” София, Издателство “Парадигма”, 2000 год
books -> Книга 2 щастие и успех предисловие
books -> Превръщане на числа от една бройна система в друга
books -> Тантриското преобразяване
signatures -> Java за цифрово подписване на документи в уеб


Сподели с приятели:
1   ...   6   7   8   9   10   11   12   13   14




©obuch.info 2024
отнасят до администрацията

    Начална страница