Цифрово подписване на документи в Java-базирани Web-приложения



Дата23.02.2017
Размер202.36 Kb.

Цифрово подписване на документи в Java-базирани Web-приложения

Резюме


... не е изчистено, но за това има време ...

Настоящата разработка има за цел да запознае читателя с проблемите, свързани с електронното подписване на документи в Java-базирани Web-приложения и да предложи подходи за тяхното решаване. Първоначално ще направим кратък преглед на основните понятия, свързани с електронния подпис, след което ще обясним основните библиотеки от класове, които Java 2 платформата предоставя за работа с електронни подписи, а след това ще дадем конкретен пример за реализация на система за цифрово подписване на документи в Web-приложения, базирани на Java 2 платформата.


Основни понятия, свързани с цифровия подпис


При предаването на важни документи по електронен път често се налага да се удостовери по надежден начин кой в действителност е изпращач (автор) на даден документ. Един от подходите за удостоверяване на произхода на документи и файлове е чрез използването на т. нар. цифров подпис (електронен подпис).

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



Криптографията, базирана на публични ключове (public key cryptography) е математическа наука, която се използва за осигуряване на конфиденциалност и автентичност при обмяната на информация чрез използването на криптографски алгоритми, работещи с публични и лични ключове. Тези криптографски алгоритми се използват за електронно подписване на документи, проверка на електронен подпис, шифриране и дешифриране на документи.

Инфраструктурата на публичния ключ (public key infrastructure – PKI) предоставя архитектурата, организацията, техниките, практиките и процедурите, които подпомагат чрез цифрови сертификати приложението на криптографията, базирана на публични ключове (public key cryptography) за целите на сигурната обмяна на информация по несигурни мрежи и преносни среди, като например Интернет.

Публичните и личните ключове представляват математически свързана двойка криптографски ключове (public/private key pair). На всеки публичен ключ съответства точно един личен ключ и обратното – на всеки личен ключ съответства точно един публичен ключ. За да използва криптография с публични ключове едно лице трябва да притежава двойка публичен ключ и съответен на него личен ключ.



Публичният ключ (public key) представлява число (последователност от битове), което обикновено е свързано с дадено лице. По идея публичният ключ на дадено лице трябва да е известен на всички, с които това лице си комуникира, използвайки криптография с публични ключове. Публичните ключове не представляват тайна за никого и обикновено са публично достъпни. Един публичен ключ може да се използва за проверка на цифрови подписи, създадени със съответния му личен ключ, както и за шифриране на документи, предназначени да бъдат дешифрирани само от притежателя на съответния личен ключ.

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

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



Цифровите сертификати свързват определен публичен ключ с определено лице. Те се издават от специални организации, на които се има доверие (сертифициращи организации) при строги мерки за сигурност, които гарантират тяхната достоверност. Цифровите сертификати можем да възприемаме като електронни документи, удостоверяващи, че даден публичен ключ е собственост на дадено лице. В практиката за целите на електронния подпис най-масово се използват X.509 v.3 сертификати.

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

Сертифицираща организация (certification authority – CA) е институция, която е упълномощена да издава цифрови сертификати и да ги подписва със своя личен ключ. Целта на сертификатите е да потвърдят, че даден публичен ключ е притежание на дадено лице, а целта на сертифициращите организации е да потвърдят, че сертификатите са валидни и може да им се вярва. В този смисъл сертифициращите организации се явяват безпристрастна доверена трета страна, която осигурява висока степен на сигурност и доверие на компютърно-базирания обмен на информация. Ако една сертифицираща организация е издала цифров сертификат на дадено лице и се е подписала, че този сертификат е наистина на това лице, можем да вярваме, че публичният ключ, който е записан в сертификата, е наистина на това лице, но само при условие, че имаме доверие на тази сертифицираща организация. Сертификат, който е подписан от сертифицираща организация, на която имаме доверие и не е с изтекъл срок на валидност, се нарича проверен (verified).

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

Не на всички сертифициращи организации може да се вярва, защото е възможно злонамерени лица да се представят за сертифицираща организация, която реално не съществува или е фалшива. За да се вярва на една сертифицираща организация, тя трябва да е световно утвърдена и призната. В света на цифровата сигурност утвърдените световни сертифициращи организации разчитат на много строги политики и процедури за издаване на сертификати и благодарение на тях поддържат доверието на своите клиенти. За по-голяма сигурност тези организации използват специален хардуер за съхранение на личните си ключове, който гарантира невъзможността за изтичане на информация. Примери за известни световни сертифициращи организации, които са възприети като надеждни и на които може да се вярва са: VeriSign, GTE CyberTrust, Thawte Consulting, GlobalSign, TC TrustCenter, Baltimore CyberThrust и др.

Всяка сертифицираща организация има свой сертификат и с него подписва сертификатите, които издава на своите клиенти. Една сертифицираща организация може да бъде от първо ниво (top-level certification authority или Root CA) или да бъде на някое следващо ниво. Сертифициращите организации от първо ниво при започването на своята дейност издават сами на себе си сертификат, който подписват с него самия. Такива сертификати се наричат Root-сертификати. Root-сертификатите на известните световни сертифициращи организации са публично достъпни от техните сайтове и могат да се използват за верификация на други сертификати. Сертифициращите организации, които не са на първо ниво разчитат на някоя организация от по-горно ниво да им издаде сертификат, с който имат право да издават и подписват сертификати на свои клиенти. По принцип всеки сертификат може да бъде използван за да се подпише всеки друг сертификат, но за да се има доверие на един сертификат, той трябва да е подписан от организация, която е специално упълномощена да издава сертификати на свои клиенти. Ако един потребител си купи сертификат от някоя сертифицираща организация, примерно от VeriSign и подпише с него друг сертификат, новоподписаният сертификат няма да се ползва с доверие, защото ще e подписан от сертификат, който не е упълномощен да се използва за подписване на други сертификати. Всеки сертификат съдържа информация за това дали може да бъде използван за подписване на други сертификати.

Един сертификат може да бъде подписан от друг сертификат (най-често от сертификат на някоя сертифицираща организация) или да е подписан от самия себе си. Сертификатите, които не са издадени от някоя сертифицираща организация, а са подписани от себе си, се наричат собственоръчно-подписани сертификати (self-signed certificates). На такива сертификати не трябва да се вярва, защото с подходящ софтуер всеки може да си генерира self-signed сертификат на името на избрано от него лице или фирма. Ако един сертификат удостоверява, че даден публичен ключ е на дадено лице или фирма, това трябва да е сертификат, издаден от някаква сертифицираща организация, а не self-signed сертификат. Един self-signed сертификат не може да удостоверява връзка между публичен ключ и дадено лице.

Собственоръчно-подписаните сертификати все пак имат свое приложение, например във вътрешно-фирмени системи, където е възможно сертификатите да се разпространят физически по сигурен начин между отделните системи и служители. В такава среда не е необходимо някоя сертифицираща организация да потвърждава, че даден публичен ключ е на дадено лице, защото това се гарантира от начина на обмяна на сертификатите. Например при постъпване на нов служител в дадена фирма е възможно системният администратор да издава self-signed сертификат на новия служител и му го дава на дискета или по друг сигурен път, при който трети лица не могат да го подменят. От този момент нататък вътрешно-фирмените системи знаят със сигурност, че този сертификат е на този служител, а служителят знае, че вътрешно-фирмените системи имат неговия истински сертификат и така надеждната комуникация в рамките на фирмата е възможна и без използването на проверени (verified) сертификати. Не е такъв, обаче случаят при комуникация по Интернет, където няма сигурен начин да се установи дали даден сертификат, изпратен по мрежата не е подменен някъде по пътя. За защита от такива проблеми всички Web-браузъри имат списък от Root-сертификатите на най-известните сертифициращи организации и вярват само на сертификати, подписани с някой от тези сертификати. Ако един Web-сървър в Интернет трябва да комуникира с Web-браузъри по защитен комуникационен канал (SSL), той непременно трябва да притежава сертификат, издаден от някоя известна сертифицираща организация. В противен случай е възможно криптираните връзки между клиентите и този Web-сървър да се подслушват от трети лица.

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

Когато една сертифицираща организация от първо ниво издава сертификат на свой клиент, тя го подписва с някой от своите Root-сертификати. Така се създава верига от сертификати, състояща се от два сертификата – този на сертифициращата организация и този на нейния клиент. Вериги от сертификати (сертификационни вериги, certificate chains) се наричат последователности от сертификати, за които всеки следващ е подписан от предходния. Обикновено в началото на веригата стои Root-сертификата на някоя сертифицираща организация, в края на веригата стои някакъв сертификат, издаден на краен клиент, а в средата на веригата стоят сертификатите на някакви междинни сертифициращи организации. В типичния случай някоя сертифицираща организация от първо ниво издава сертификат на някоя междинна сертифицираща организация, като отбелязва в този сертификат, че той може да бъде използван за издаване на други сертификати. Междинната сертифицираща организация издава сертификати на свои клиенти или на други междинни сертифициращи организации. Сертификатите, издадени на крайни клиенти и тези, издадени на други междинни сертифициращи организации се различават по правата, които са им зададени. Сертификатите, издадени на крайни клиенти имат такива права, че не могат да бъдат използвани за издаване на други сертификати, защото на един краен клиент не може да се има доверие, докато на една сертифицираща организация може.

На един сертификат, който се намира на края на дадена сертификационна верига може да се вярва само ако сертификационната верига бъде успешно верифицирана. В такъв случай се казва, че този сертификат е проверен (verified). Верификацията на една сертификационна верига включва проверка дали всеки от сертификатите, които я съставят, е подписан от предходния сертификат във веригата, като за началния сертификат се проверява дали е в списъка на Root-сертификатите, на които безусловно се вярва. Всеки софтуер за верификация на сертификати поддържа списък от доверени Root-сертификати (trusted certificates), на които вярва безусловно. Например Web-браузърът Internet Explorer идва стандартно със списък от около 150 доверени Root-сертификата, а браузърът Mozilla при първоначална инсталация съдържа около 70 доверени сертификата. Проверката на една сертификационна верига включва не само проверка на това дали всеки сертификат е подписан с предходния и дали сертификатът в началото на тази верига е в списъка на доверените Root-сертификати. Необходимо е още да се провери дали всеки от сертификатите във веригата не е с изтекъл срок на валидност, а също дали всеки от сертификатите без последния има право да бъде използван за подписване на други сертификати. Ако проверката на последното условие се пропусне, ще стане възможно краен клиент да издава сертификат на името на когото си поиска и верификацията да преминава успешно. Освен това при проверката за валидност на дадена сертификационна верига се проверява също дали някой от сертификатите, съставящи веригата не е анулиран (revoked). Съвкупността от всичките описани проверки може да установи, че на един сертификат може да се вярва. Ако проверката на една сертификационна верига не е успешна, това не означава непременно, че има опит за фалшификация. Възможно е списъкът на доверените Root-сертификати, използван при верификацията, да не съдържа Root-сертификата от началото на веригата, въпреки че той е истински. Един сертификат не може да бъде верифициран, ако не е налична цялата му сертификационна верига или ако Root-сертификата, с който започва веригата му, не е в списъка на доверените сертификати. Сертификационната верига на един сертификат може да се построи и програмно, ако не е налична, но за целта трябва да са налични всички сертификати, които участват в нея.

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

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

За съхранение на X.509 цифрови сертификати има няколко стандарта. Най-често се използва стандарта ASN.1 DER, при който сертификатите се записват във файлове с разширение .CER (и в по-редки случаи с разширение .CRT). Един CER файл съдържа публичен ключ, информация за лицето, което е негов собственик и цифров подпис на някоя институция (certification authority), удостоверяващ че този публичен ключ е наистина на това лице. Сертифициращите организации разпространяват своите Root-сертификати като CER файлове, които са достъпни от техните сайтове.

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

Сертифициращите организации периодично (или по неотложност) издават списъци на определени сертификати, които са с временно преустановено действие или са анулирани преди изтичане на срока им на валидност. Тези списъци се подписват цифрово от сертифициращата организация, която ги издава и се наричат списъци на анулираните сертификати (certificate revocation lists – CRL). В един такъв списък се посочват името на сертифициращата организация, която го е издала, датата на издаване, датата на следващото издаване на такъв списък, серийните номера на анулираните сертификати и специфичните времена и причини това анулиране.

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

Цифровият подпис служи за същите цели, както и обикновения подпис (който се поставя върху документи на хартия), но между двете категории подписи има съществени разлики. Една от тези разлики е, че цифровият подпис гарантира интегритета на документа, т.е. гарантира, че документът не е променян след момента на подписването му, докато при обикновените подписи това не е възможно. Друга съществена разлика между обикновения подпис и цифровия подпис е, че цифровият подпис изключително трудно би могъл да бъде фалшифициран, за разлика от обикновения. Друга разлика е, че за свързване на един обикновен подпис с дадено лице е необходима съдебна експертиза, докато за свързването на един цифров подпис с дадено лице е необходим единствено проверения сертификат на лицето, което го е положило. За разлика от обикновения подпис, електронният подпис може да бъде полаган не само от лицето, което го притежава. Възможно е злонамерени лица без знанието на лицето-собственик да подписват документи с неговия подпис. Такава ситуация може да се получи когато поради някаква причина частният ключ на дадено лице бъде откраднат (прекопиран). При обикновените подписи на хартия ако злонамерено лице подпише друго лице, измамата почти винаги може да бъде разкрита чрез съдебна експертиза, докато при цифровия подпис разкриването на евентуална злоупотреба не винаги е възможно. За решаването на този проблем в много организации е въведена употребата на смарт-карти (smart cards).



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

Как работи цифровият подпис


Едно лице полага цифров подпис под дадено електронно съобщение (файл, документ, e-mail и др.) чрез личния си ключ. Реално цифровото подписване на едно съобщение се извършва на две стъпки:

На първата стъпка се изчислява хеш-стойност на съобщението (message digest) по някакъв криптографски алгоритъм за хеширане (например MD4, MD5, SHA1 или друг). Хеш-стойността на едно съобщение представлява последователност от битове, обикновено с фиксирана дължина. Алгоритмите, които изчисляват хеш-стойност са такива, че при промяна дори на само 1 бит от входното съобщение се получава тотално различна хеш-стойност. Това поведение на тези алгоритми ги прави изключително устойчиви на криптоаналитични атаки., т.е. почти е невъзможно от дадена хеш-стойност на едно съобщение да се намери самото съобщение. Тази невъзможност за възстановяване на входното съобщение е съвсем логична, като се има предвид, че хеш-стойността на едно съобщение може да има стотици пъти по-малък размер от него самото. Възможно е два напълно различни документа да имат една и съща хеш-стойност, но вероятността това да се случи е толкова малка, че на практика тази възможност се пренебрегва.

На втората стъпка от цифровото подписване получената хеш-стойност на съобщението се шифрира с личния ключ, с който се извършва подписването. За целта се използва някакъв математически алгоритъм за цифров подпис (digital signature algorithm), който преобразува хеш-стойността в шифрирана хеш-стойност, наричана още цифров подпис. Най-често се използват алгоритмите RSA (който се основава на теорията на числата), DSA (който се основава на теорията на дискретните логаритми) и ECDSA (който се основава на теорията на елиптичните криви). Полученият цифров подпис често пъти се прикрепя към края на съобщението в специален формат, за да може да бъде верифициран на по-късен етап, когато това е необходимо.

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

Технически погледнато проверката на цифров подпис се извършва на три стъпки:

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

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

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



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

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

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

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

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

Използване на цифрови подписи в Java


За целите на подписването на документи, проверка на цифровия подпис и управление на цифрови сертификати в Java платформата се използва Java Cryptography Architecture (JCA). JCA представлява спецификация, която предоставя на програмистите достъп до криптографски услуги, работа с цифрови подписи и сертификати. От архитектурна гледна точка JCA е така проектирана, че да позволява различни имплементации от различни софтуерни доставчици. При работата с JCA програмистът избира имената на доставчиците на криптографски услуги (provider) и имената на алгоритмите, които иска да използва. Различните доставчици на криптографски услуги реализират различно множество от криптографски алгоритми, достъпни по име. Спецификацията JCA установява стандарти за различните типове криптографски услуги и специфицира начина на използване на криптографските алгоритми. Реализацията на самите алгоритми е оставена на софтуерните доставчици. Стандартно с JDK 1.4 и всяка следваща версия се разпространява и имплементация на JCA, която се използва по подразбиране, ако програмистът не посочи някоя друга.

Архитектурата JCA предоставя класове и интерфейси за работа с публични и частни ключове, цифрови сертификати, подписване на съобщения, проверка на цифрови подписи и достъп до защитени хранилища за ключове и сертификати. Тези класове и интерфейси се намират в пакетите java.security и java.security.cert. Ще дадем кратко описание на най-важните от тях:

java.security.KeyStore – използва се за достъп до защитени хранилища за ключове и сертификати. Предоставя методи за (съгласно PKCS #12 стандарта) и по-точно за извличане на ключове и сертификати от PFX файлове.

java.security.cert.X509Certificate – представлява X.509 сертификат.

java.security.PrivateKey – представлява частен ключ.

java.security.PublicKey – представлява публичен ключ.

java.security.Signature –предоставя функционалност за подписване на документи и проверка на цифрови сигнатури.

java.security.cert.CertificateFactory – предоставя функционалност за зареждане на сертификат от поток.

... малко обяснения как се използват цифрови подписи в Java – малко за JCA (Java Cryptography API), какви класове предлага, как се ползват ...

Класовете за проверка и построяване на сертификационни вериги са специфицирани в Java Certification Path API.


Система за подписване на документи в Web-приложения NakovDocumentSigner


... представяне на freeware системата за електронен подпис NakovDocumentSigner, описание на проблемите, как се решават, описание на аплета и на верифициращата част, от къде може да се дръпне сорса и т.н. ...

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



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

Използвана литература


  1. Общи условия на публични сертификационни услуги на GlobalSign, раздел 13.1 (дефиниции) – http://www.bia-bg.com/globalsign.bg/cps_chapter13.htm

  2. Работа с PGP – http://www.ecs.ru.acad.bg/rk2/StProj/4/pgp/overview.htm




База данных защищена авторским правом ©obuch.info 2016
отнасят до администрацията

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