Заявяване на авторство върху свободно съдържание чрез удостоверение за време

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Общо описание на удостоверяването на време и приложимостта му

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

Компилиране на openssl с поддръжка на TS клиент

Създаване на директория за съхранение на сертификатите

Генериране и преглед на заявката за удостоверение за време

Изпращане на заявката за удостоверяване на време към системата на издателя

Проверка за валидност на удостоверение за време чрез openssl

Преглед на съдържанието на удостоверението за време

Транзитивност на удостоверяването при използване на OpenPGP за подписване на съдържанието

Защо използването на OpenPGP за подписване на съдържанието е по-надеждно

Графичен TS клиент на Банксервиз

Използване на графичния TS клиент на Банксервиз чрез емулатора Wine

Издаване на едно удостоверение за време за набор от файлове (съдържания)

Срок на валидност на издадените удостоверения за време

1. Общо описание на удостоверяването на време и приложимостта му

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

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

За какво служи издаденото удостоверение за време и каква документна стойност има то? Удостоверението за време служи само и единствено като свидетелство, че към момента от време, отбелязан в него, на заявителя е бил известен хеш с някаква стойност, описана в удостоверението. Самият удостоверител на време по право не е виждал съдържанието, от което е изчислен хеша. Предполага се, че той е изчислен от заявителя, но ако следва да бъдем детайлни, би следвало да споменем, че това не е задължително, защото е възможно друго лице да е съобщило хеша на заявителя и последния да го е вложил в заявката изпратена до удостоверителя. Възможно е дори заявителя да е измислил някакво N-битово число, което да съответства като разред на резултата от използването на някоя от стандартните хеш функции и да го е заявил, кото значи, че дори не е нужно на числото, представляващо хеша, да съответства някакво съдържание. Последното обаче не носи никаква практическа стойност.

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

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

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

2. Използвани удостоверители на време

След анализ на всички удостоверители, сертифицирани като такива по Закона за електронния подпис и електронния документ, от регулатора КРС, се установи, че единствено „БАНКСЕРВИЗ“ АД имат нормално достъпна за всеки услуга за удостоверяване на време, която работи в обществена полза и заслужават адмирации за нейното създаване и поддръжка.

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

Именно поради написаното по-горе, всички примери надолу са обвързани с удостоверителя „БАНКСЕРВИЗ“ АД. Услугата на тази организация позволява изпращане на файла със заявката от клиентския браузър към подписващата система, чрез формата на адрес:

3. Компилиране на openssl с поддръжка на TS клиент

Процесът по-долу е необходим само, ако в използваната дистрибуция не съдържа стандартно в себе си инструмента openssl или наличния такъв не поддържа TS клиент. Проверка за това дали наличния инстумент openssl поддържа TS клиент, може да се направи от команден ред (като непривилигерован потребител) така:

Ако сред изведените опции се намира "ts" (виж секция "Standard commands"), то openssl поддържа TS клиент и не е нужно да се извършва описания по-долу процес на компилация и инсталация.

Наличният в повечето Linux дистрибуции инструмент openssl, не поддържа TS клиентска част, доколкото тя не е налична в дистрибутирания изходен код на проекта OpenSSL. Това обстоятелство налага да се приложат кръпки към изходния код на OpenSSL така, че след компилирането му, инструмента openssl да поддържа TS клиент. Кръпките, които трябва да се приложат за реализиране на TS клиент, са обект на разработка и поддръжка от страна на проекта OpenTSA. Последната им реализация може да бъде изтеглена от адрес:

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

За всеки набор от кръпки е посочена версията на изходния код на OpenSSL, към който те са приложими. Тази специфична приложимост силно ограничава възможността за използването на кръпките за произволна версия на OpenSSL. Въпреки това е възможно чрез поправки в изходния код на кръпките, те да се нагодят към друга версия на OpenSSL, но това изисква познания за работа с изходен код на C++.

Към момента на написване на този материал, текущия набор кръпки може да се изтегли от следния URL:

Поради вече споменатата специфичност, изтеглените кръпки са приложими без промени само за изходния код на OpenSSL във версия 0.9.8c. На страницата за изтеглянето на кръпките, срещу всеки техен набор, е указано за коя версия на кода на OpenSSL са приложими те.

Трябва да се отбележи, че не е добра идея чрез рекомпилация да се подменя наличния в системата инструмент openssl, който обикновено се инсталира от пакетната система на дистрибуцията (в повечето случаи по подразбиране). По-рационално е потребителят, който ще използва TS клиент, да приложи кръпките на проекта OpenTSA към съответната версия на кода на OpenSSL, да компилира закърпения код за себе си и да го инсталира някъде в своята домашна директория. След това да стартира при нужда мофицирания инструмент openssl.

По-долу е даден примерен набор от командни редове, чрез изпълнението на които да се компилира и инсталира в потребителската директория, инструмента openssl с поддръжка на TS клиент:

Да се обърне специално внимание на съдържанието на ред номер пет. В него се извършва проверка на архива с изходния код OpenSSL, изтеглен от файловия сървър на проекта. Всеки проект, който държи да реализира сигурна дистрибуция на софтуерен продукт и да предоставя ясна идентичност на дистрибутирания от него код, следва да подписва предоставяните за изтегляне архиви. За да може всеки потребител да установи идентичността на изтегления изходен код, следва да провери електронния подпис върху него (в случая архива е във файла openssl-0.9.8c.tar.gz). Дистрибуторът следва да подпише архива с кода преди публикуването му и да помести електронния подпис в отделен файл (в случая openssl-0.9.8c.tar.gz.asc). Проверяващият валидността на електронния подпис потребител, следва да има в своето gnupg хранилище копие от OpenPGP сертификата на проекта OpenSSL. Той може да бъде изтеглен от няколко сървъра за ключове и чрез "Web Of Trust" да се установи дали има достатъчно ниво на доверие върху него или не. След като установеното доверие върху OpenPGP сертификата бъде счетено за достатъчно, се извършва проверката показана в дискутирания команден ред номер пет. Ако след извършването й бъде изведено съобщение валиден електронен подпис ("Good signature"), то изтегления архив с голяма вероятност представлява наистина изходния код на проекта OpenSSL.

След успешния процес на компилация, инструментът openssl с поддръжка на TS клиент, би следвало да се намира в директория ${HOME}/ts/bin. Той ще бъде извикван (стартиран), само в случаите, в които се налага генериране на заявка за удостоверение на време и проверката на полученото удостоверение. За да се провери работоспособността му, е добре след приключване на процеса по инсталирането (последния команден ред от списъка по-горе), да се извърши стартиране с извеждане на наличните опции:

Сред изведените опции трябва да се намира "ts" (виж секция "Standard commands"). Нейното наличие е най-сигурния индикатор за правилното прилагане на кръпките към кода на OpenSSL.

Възможно е някои потребители да решат да поставят пътя до компилирания и инсталиран по гореописания начин инструмент openssl в състава на променливата на средата ${PATH} и то в ред, изпреварващ в каталога на пътища пътя до дистрибутивния инструмент openssl. Подобно поставяне е изключителна грешка от гледна точка на сигурността и дистрибутивния интегритет на инструментариума. Първо, разработката по прокета OpenTSA е значимо бавна и последната реализация на кръпките за реализиране на TS клиент са за стара версия на OpenSSL, в която има намерени недостатъци и потенциални опасности. Второ, дори кръпките да засягат текущата за дистрибуцията версия на OpenSSL, е почти сигурно, че в дистрибутивния пакет openssl има приложени още кръпки, които в общия случай потребителя, извършващ компилацията няма да приложи, което ще направи значима разликата между компилирания от него инструмент openssl и дистрибутивния. Трето, дистрибутивният пакет openssl е обект на актуализации, чиито темп едва ли би могъл да бъде следван от потребителя, което веднага поставя съмнение относно сигурността на постоянното използване на ръчно компилирания инструмент openssl по всякакъв повод.

Един от най-силните аргументи да не бъде използван така компилирания инструмент openssl като заместител на системния, е че изходният код на кръпките за реализиране на TS клиент не е електронно подписан и нямат ясна идентичност. Прилагането на този код без подробен нагов анализ и използването му на системно ниво, е изключителен системен риск, който не може да бъде оправдан по никакъв начин.

За момента авторът на тази документация, чрез помощта на хора с добри познания в областта на програмирането на C++ и Perl, е установил, че в изходния код на кръпките, достъпни чрез URL:

няма злонамерен програмен код. За улеснение на потребителите, по-долу са побликувани хеш суми на съдържанието на файла ts-20060923-0_9_8c-patch.gz, които те могат да използват за сравнение:

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

4. Създаване на директория за съхранение на сертификатите

Добра практика е X.509 сертификатите на издателите на удостоверения за време, да се складират в специална директория за целта. След това на инструментариума за валидиране на удостоверенията за време, се указва пътя до директорията. Всеки файл в нея съдържа в себе си един X.509 сертификат, както изисква добрата практика в тази област. Създаването й може да се извърши така:

Освен файловете споменати по-горе, в тази директория се създават символични връзки към тях, но с имена съдържащи хешираното по подходящ начин съдържание на полето "Subject" от сертификата. Чрез тези символни връзки се изгражда една проста и лесна система за бързо разпознаване на нужния на приложението сертификат. Чрез нея разпознаването на нужния сертификат става по наименованието на символната връзка. Процесът на създаване на символните връзки е автоматизиран и не е необходимо ръчно да се инициализира изчисляване на хешове. За автоматизацията се грижи инструмента c_rehash, който би следвало да се намира в директория ${HOME}/ts/bin, ако е следвана описаната по-горе процедура за инсталиране и компилиране на инструмента openssl с поддръжка на TS клиент. Този инструмент е скрипт на Perl, който се стартира след като файловете с X.509 сертификатите бъдат разположени в директория ${HOME}/ts/CA. Важна особеност, която следва да се отчита е, че c_rehash функционира само, ако файловете, които съдържат X.509 сертификатите, са с разширение в името си .pem. Работата с c_rehash може да се илюстрира със следния пример:

Доколкото всички илюстрации касаят удостоверителя "БАНКСЕРВИЗ" АД, то тук ще бъде илюстрирано изтеглянето на сертификатите за услугата и създаването на хеширани символни връзки към тях.

Като резултат от последното извикване на c_rehash, би следвало да бъде изведен:

При прибавянето на нов файл с X.509 сертификат в директорията, следва отново да се извърши процедурата по създаването на символните връзки.

5. Генериране и преглед на заявката за удостоверение за време

За извършването на описаното по-долу е нужен инструмент openssl с поддръжка на TS клиент. Процесът по генериране на заявката за удостоверение на време, зависи от това дали генериращия я има достъп до удостоверяваното съдържание или само до негов хеш, генериран от друг:

Добра практика е в заявката да се заложи изискването удостоверителя да вложи в удостоверението за време копие от X.509 сертификата на услугата за подписване на време. За целта в командния ред за генериране на заявката се включва опцията -cert (виж примерния команден ред по-горе). Чрез включване на X.509 сертификата на услугата в издаденото удостоверение за време, по-лесно се извършва проверката на електронния подпис. Улеснението идва от това, че при проверката на електронния подпис върху удостоверението, не се налага проверяващия да разполага с копие от X.509 сертификата на услугата за подписване на удостоверенията, а само с копие на удостоверителския X.509 сертификата на издателя. Това е равносилно на подаване на сертификатната верига от страна на издателя.

Прегледът на генерираната заявка е сравнително лесен. За целта може да се използва команден ред подобен на:

Резултатът от успешното му изпълнение изглежда така:

Ясно се вижда стойността на хеша, която ще бъде заявена за удостоверяване (cb8905552dd11386c1ca1ee58ce87433bf5ce722).

6. Изпращане на заявката за удостоверяване на време към системата на издателя

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

Към момента на завършване на тази документация, единствено услугата за удостоверяване на време на „БАНКСЕРВИЗ“ АД е свободно достъпна за използване от всеки заинтересован:

Чрез формата за изпращане на заявки, достъпна на този адрес, всеки може да изпрати заявка за издаване на удостоверение за време. Браузърът би следвало да изтегли автоматично генерираното удостоверение до няколко секунди след изпращането на заявката, под формата на файл с име .tsr. Този файл трябва да се наименова по подходящ начин, така че да се асоциира със съдържанието, което удостоверява.

Съдържанието, заявката и удостоверението, следва да се пазят на сигурно място, с оглед предотвратяване на изгубването им, тъй като те могат да се разглеждат като доказателствен материал.

7. Проверка за валидност на удостоверение за време чрез openssl

За да може да се извърши описаната по-долу проверка на валидността на удостоверенията за време, е необходим инстумент openssl с поддръжка на TS клиент. На разположение на инструмента следва да е X.509 сертификата за проверка на подписа на издателя върху удостоверението. Инсталирането на този сертификат може да се извърши съгласно указанията в "Създаване на среда за съхранение на сертификатите".

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

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

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

Преглед на съдържанието на удостоверението за време

За да може да се извърши преглед на съдържанието на удостоверение за време, е необходим инстумент openssl с поддръжка на TS клиент.

Прегледът на съдържанието на удостоверението за време позволява да се установи точното време, в което издателя е подписал заявката. Това време няма как да се види при някоя от другите операции, свързани с валидиране на удостоверението, поради особената конструкция на използвания TS клиент. Прочита на съдържанието на удостоверението трябва да се извършва само след проверката му за валидност. В противен случай това съдържание е недостоверно.

Ако удостоверението за време се намира във файла parse.bash.tsr, то прегледът на съдържанието му се извършва чрез команден ред подобен на:

Визуализираното по този начин съдържание изглежда приблизително по следния начин:


Status info:

Status: Granted.

Status description: unspecified

Failure info: unspecified



TST info:

Version: 1

Policy OID: 1.1.2

Hash Algorithm: sha1

Message data:

  0000 - cb 89 05 55 2d d1 13 86-c1 ca 1e e5 8c e8 74 33  9..R&..8..].k.1.

  0010 - bf 5c e7 22                                      ....

Serial number: 0x0E384D

Time stamp: May 31 19:57:53 2008 GMT

Accuracy: 0x3C seconds, unspecified millis, unspecified micros

Ordering: yes

Nonce: unspecified

TSA: DirName:/C=BG/L=Sofia/O=Bankservice PLC - BULSTAT U 000640954/OU=B-Trust/CN=B-Trust Time Stamp Authority/streetAddress=41, Tzar Boris III blvd./postalCode=1612/emailAddress=ca3@b-trust.org/2.5.4.20=+359 2 9 215 100

Extensions:

В този примерен изход има три важни параметъра, чиито стойности са хеша на удостоверяваното съдържание, времето на извършване на удостоверяването и данните за идателя му. Доколкото обект на удостоверението за време е винаги някакъв хеш на съдържанието, той е представен като стойност на параметъра Message data. Полето с хеша съдържа два реда и две колонки. Хешът е изписан в явен вид (ASCII) и на двата реда в първа колонка (за примера по-горе стойността на хеша е cb8905552dd11386c1ca1ee58ce87433bf5ce722). Стойността на най-важния параметър, времето на подписване, е указана като стойност на параметъра Time stamp и винаги е в гринучко време, но с времеотчитане спрямо конвенцията за UTC. Данните за издателя са представени като стойност на параметъра TSA. За горния пример издателят е "БАНКСЕРВИЗ" АД.

За да бъде конвертирано времето в удостоверението към локалното време, зададено в системата и отчитащо местния часови пояс, може да се използва командния ред:

където след "-d" се указва времето зададено в удостоверението.

9. Транзитивност на удостоверяването при използване на OpenPGP за подписване на съдържанието

Често срещано мнение е, че удостоверението за време е валидно само, ако заявката за издаването му касае електронен подпис, който е извършен с помощта на X.509 сертификат за универсален електронен подпис, издаден от някой от признатите по закон удостоверители в Република България. Подобно мнение е спекулативно и погрешно поради причини свързани с транзитивното удостоверяване, което има място в този случай. За съжаление непознаването на криптографските системи и теорията и практиката на удостоверителния процес, както и създаваните удостоверителски вериги, е често срещано явление дори сред доставчиците на удостоверителни услуги, които следва да са най-добре запознатите с тази материя.

Нека представим за пример следния случай. Трябва да покаже по проверим начин, че файла file.txt е имал точно определно съдържание към някакво време, но без за това да се използва X.509 сертификат за универсален електронен подпис, издаден от законово признатите удостоверители. Най-лесният начин да бъде направено това е чрез използване на OpenPGP сертификат. Електронният подпис върху съдържанието се извършва чрез използване на OpenPGP сертификата и съответния софтуер, например gpg:

Полученият по този начин електронен подпис е отделяем от удостоверяваното съдържание и ще се намира във файла file.txt.asc. След това удостоверението за време се издава за файла file.txt.asc, а не за file.txt. По този начин издаденото удостоверение показва, че в посочения в него момент от време, електронния подпис върху документа е съществувал. Доколкото само притежателят на частния ключ може да извърши този подпис, потвърждаем с публичния му ключ от OpenPGP сертификата, то има ясна идентичност относно това кой е подписан електронно въпросното съдържание към посоченото в удостоверението време.

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

10. Защо използването на OpenPGP за подписване на съдържанието е по-надеждно

За съжаление практика на удостоверителите на X.509 сертификати е, да организират така предоставяната услуга, че клиента да генерира двойка ключове, в която частния ключ е с дължина 1024 бита. Тази практика по използването на сравнително къс подписващ ключ при лесно достъпна и евтина изчислителна мощност, с която да се извършват опити за пресмятане на частния ключ по известния му публичен, е опасна и необоснована от гледна точка на съвремените изследвания в криптоанализа. Лошата практика не спира до тук. Удостоверителите въвеждат "подновяване" на X.509 сертификат, при което същата двойка ключове, която е използвана за основа на предишния издаден X.509 сертификат, се използва за издаване на нов такъв. Пренебрегват се изискванията за сигурност, които не препоръчват използване на двойка с такъв къс подписващ ключ за повече от 1 календарна година. Систематичното предподновяване на един сертификат основан на къс подписващ ключ с години, го подлага на опасност от разкриване.

Издаваните съгласно българското законодателство X.509 сертификати са направо опасни за титуляра им. В мета полето "Subject" на сертификата се намира лична информация като ЕГН, адрес, телефон. От друга страна X.509 сертификатът следва да е публичен, което автоматично прави публични и личните данни в него. Ако титулярът на сертификата откаже вписването им в мета полето "Subject", той губи възможността да придобие X.509 сертификат за извършване на универсален електронен подпис.

Съгласно съвремените приложения, сертификатният модел OpenPGP е приложим стандартно за дължини на подписващия ключ до 4096 бита, което може да даде огромна сигурност в сравнение с 1024 битов ключ. Софтуер за работа с модела OpenPGP, като GnuPG, позволява генерирането на ключове с дължина 4096 бита, които може да са валидни за срок определен от създателя им и вложен като параметър в съответния OpenPGP сертификат. GnuPG позволява и лесното използване на хеш функции с по-голямо пространство на реализации от SHA-1, а именно SHA512. Това означава, че OpenPGP и софтуера, който го използва, дори само чисто принципно, повишават нивото на сигурност.

11. Графичен TS клиент на Банксервиз

За съжаление към момента на написване на този материал, на автора не са известни клиенти с графичен интерфейс или дори използваеми от команден ред, които да съчетават в себе си възможностите показани по-горе.

Инструментът предоставян от Банксервиз е със затворен код, но той реализира само визуализатор, което донякъде смегчава използването на затворен код за цели свързани с персонална сигурност и авторство. Всички процеси свързани с обработката на заявките и удостоверенията се извършват от библиотеките на OpenSSL, които са компилирани отделно (и се предлагат отделно). Ако потребителят желае това, той сам може да компилира тези библиотеки на OpenSSL с поддръжка на TS клиент за Windows и да използва тях.

OpenSSL библиотеките с поддръжка на TS клиент (двоични и изходен код) и изпълнимия код на програмата-визуализатор, са достъпни на адрес http://www.b-trust.org/?p=soft в секцията "5. Time Stamp клиент".

Тук могат да се дадат следните препоръки към "БАНКСЕРВИЗ" АД:

12. Използване на графичния TS клиент на Банксервиз чрез емулатора Wine

Преди да се премине към използване на Wine, следва да се приготви директория, в която да се инсталира приложението и библиотеките на OpenSSL с поддръжка на TS клиент.

Само за примера тук, ще се използва директорията ${HOME}/ts/windows. Процедурата по създаване, изтегляне на софтуера и инсталирането му, може да се опише по следния начин:

За да се стартира приложението за генериране, преглед и проверка на удостоверения за време под Linux, FreeBSD, Mac OS X или Solaris базирани системи, е необходимо използването на емулатора Wine. Ако той не е наличен в конкретната система, следва да се инсталира от пакетната колекция или да се компилира от изходен код. Примерът за инсталиране на Wine от пакетна колекция, даден по-долу, касае Linux дистрибуциите Fedora (текущи поддържани версии), Red Hat Enterprise Linux 4 и 5 и производните им (напр. CentOS 4 и 5 или Scientific Linux 4 и 5). Специално за Red Hat Enterprise Linux 4 и 5 (и производните им), е нужно използването на пакетното хранилище EPEL. В споменатите дистрибуции инсталирането на Wine може да стане от команден ред (с ефективни права на root) по следния начин:

Разбира се, могат да бъдат използвани и графични инсталатори от рода на up2date, pirut, yumex или PackageKit (включен във Fedora).

Стартирането на приложението за генериране, преглед и проверка на удостоверения за време под Linux, FreeBSD, Mac OS X или Solaris базирани системи най-лесно става от команден ред:

При успешното емулиране на приложението tsa_client.exe чрез wine, ще се появи главния му прозорец:

По-долу са показани илюстрации на операциите извършвани с приложението, по създаване на заявка и проверката на валидност на удостоверението за време. При първото си стартиране, wine по подразбиране създава в директория ~/.wine/dosdevices символни връзки към дискови устройства, които след това се използват от емулираните приложения:

Примерният изход от изпълнението на горния команден ред би дал реализиращите дискови устройства символи връзки:

Удобно е домашната директория на потребителя да се декларира като самостоятелно дисково устройство, достъпно за емулираните приложения. Това може да стане така:

Следователно по този начин домашната потребителска директория ще бъде достъпна за емулираните приложения като устройство "Y:".

13. Издаване на едно удостоверение за време за набор от файлове (съдържания)

За илюстрация нека разгледаме набор от файлове с техните съдържания:

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

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

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

Този файл съдържа "цифровите отпечатъци" (хешовете) на файловете и следователно чрез съдържанието му могат да бъдат удостоверени всички съдържания на тези файлове към настоящия момент от време. За целта hashes.sha1 се подписва електронно, например с gpg:

и за получения отделяем подпис във файла hashes.sha1.asc се издава удостоверение за време.

14. Срок на валидност на издадените удостоверения за време

Един изключително интересен и дискусионен въпрос е какъв е срока на валидност на издадените удостоверения за време. Погледнато строго технически, срокът на удостоверение за време следва да изтича с изтичането на X.509 сертификата, който го удостоверява, защото тогава електронния подпис върху удостоверението би следвало да се счита за невалиден. Нека дадем отново пример с "БАНКСЕРВИЗ" АД. По-долу са изведени данните за текущия X.509 сертификат, чрез който се проверява валидността на електронния подпис на издателя върху удостоверенията за време, издавани от "БАНКСЕРВИЗ" АД. Данните могат да бъдат поолучени чрез следния команден ред:

Показаното означава, че електронният подпис върху издадените от "БАНКСЕРВИЗ" АД удостоверения за време, ще е валиден до 28 ноември 2010 година. Това е сравнително кратък срок на влидност.

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

Въпреки това следва да се отбележи масово използваната лоша практика (в това число и от "БАНКСЕРВИЗ" АД), при която с частния ключ, комплементарен към даден X.509 сертификат, се издават електронни подписи до момент от време, твърде близък до момента на изтичане на валидността на сертификата. Защо това е лоша практика? Лоша практика е, защото излиза, че едни от издадените електронни подписи са по-дългоживущи от другите (оттам същото касае и удостоверенията за време). Ако погледнем примера по-горе излиза, че ако на някой е било издадено удостоверение за време през 2005-та година, то е много по-дългоживущо от това издадено през 2008-ма. Излиза така, че се въвежда скрита преоценка на качеството на издаваните удостоверения за време. При това никъде не се уведомява клиента за това.

Добрата практика в случая би била да се генерира двойка ключове (с дължина на подписващия ключ поне 4096 бита), на база на публичния ключ да се издаде X.509 сертификат с валидност поне 10 години и с частния ключ да се подписват удостоверения за време само за период от една година ("оперативно време"). През останалите 9 години на своята валидност, X.509 сертификатът е използваем само за проверка на вече издадените удостоверения за време. Малко преди изтичането на оперативното време, се издава друга двойка и X.509 сертификат, който пак се използва за едногодично издаване на удостоверения за време и последваща 9 годишна валидация и т.н.