Освен аплетът, който подписва изпращаните от потребителя файлове, нашата уеб-базирана информационна система трябва да реализира и функционалност за посрещане на тези подписани файлове заедно с проверка на получената сигнатура. Необходимо е още получените клиентски сертификати и сертификационни вериги също да бъдат проверявани, за да е ясно кой всъщност подписва получените файлове. Да разгледаме проблемите, свързани с тези проверки.
2.3.1.Система за верификация на цифровия подпис
Проверката на цифровия подпис има за цел да установи дали изпратената сигнатура съответства на изпратения файл и на изпратения сертификат, т.е. дали тя е истинска. Тази проверка се осъществява по стандартния начин за верификация на сигнатури – от сертификата на изпращача се извлича публичният му ключ и се проверява дали сигнатурата на получения документ е направена със съответния му личен ключ.
Проверката на получения сертификат има за цел да установи дали публичният ключ, записан в него, е наистина собственост на лицето, на което сертификатът е издаден, т. е. дали потребителят е наистина този, за когото се представя при подписването. Тази проверка е по-сложна и изисква предварителна подготовка.
Има няколко механизма за верификация на цифрови сертификати. Ние ще разгледаме два от тях. При 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
|
Сподели с приятели: |