Спосіб перевірки справжності позначки про сплату поштового збору

1. Спосіб перевірки справжності позначки про сплату поштового збору, проставленої на поштовому відправленні за допомогою франкувального ключа, який полягає в дешифр уванні криптографічної інформації, що міститься у позначці, і в користуванні нею для перевірки справжності цієї позначки, який відрізняється тим, що утворюють ключ даних і передають його від центральної системи убезпечення платежів до локальних систем убезпечення платежів, які його імпортують, а результат імпортування передають до центральної системи убезпечення платежів і після успішного імпортування ключа даних суттєво всіма локальними системами убезпечення платежів ключ даних (КД) звільняють для формування нової позначки. 2. Спосіб за п.1, який відрізняється тим, що до ключа даних додають кінцеву дату для попереднього ключа і/або його передають разом з цією кінцевою датою. 3. Спосіб за п.2, який відрізняється тим, що франкувальний ключ передають до криптографічного елемента, який виконує перевірку, чи мають інші ключі даних кінцеву дату і чи кінцева дата, збережена для наступного ключа даних, передує даті, збереженій у системі убезпечення платежів. 4. Спосіб за будь-яким з попередніх пунктів, який відрізняє ться тим, що до ключа даних додають лічильник версій і/або його передають разом з цим лічильником версій. 5. Спосіб за п.4, який відрізняється тим, що ключ даних передають до криптографічного еле 2 (19) 1 3 84861 4 18. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що ключ даних або щонайменше частина ключа даних є компонентом франкувального ключа для створення позначки про сплату поштового збору. Винахід стосується способу верифікації аутентичності поштового штемпелю, генерованого з використанням франкувального ключа і застосованого до поштової кореспонденції, причому у процесі застосування цього способу криптографічна інформація, яка міститься у поштовому штемпелі, дешифрується і використовується для верифікації аутентичності цього поштового штемпелю. Існують відомі процедури забезпечення поштови х кореспонденцій цифровим поштовим штемпелем. Для полегшення отримання поштового штемпелю відправником поштової кореспонденції можна, наприклад, застосувати франкувальну систему, що використовується у Deutche Post AG, отримувати поштові штемпелі у системі клієнта і надсилати їх на принтер через будь-який інтерфейс. Спосіб такого типу описано у [заявці DE 1000 20 402 А1]. Для виключення шахрайського використання цього методу, цифровий поштовий штемпель містить криптографічну інформацію, наприклад, про дійсність системи клієнта, яка контролює продукування поштових штемпелів. [У міжнародній заявці WO 01/17160 А1] описано спосіб розподілення ключів, які генеруються центральним вузлом менеджменту і передаються у зашифрованій формі розподілю-вальним вузлом до шифрувальних пристроїв. Ці пристрої через розподілювальний вузол надсилають повідомлення про успішний або неуспішний прийом ключа до вузла менеджменту. Якщо прийом ключа є неможливим, інформація про це знову передається у нешифрованій формі до належного шифр увального пристрою. [В Європейському патенті EP 0 854 444 А2] описано спосіб шифрування і перевірки поштового штемпелю, сформованого франкувальною машиною. Тут на основі головного ключа, застосованого у франкувальній машині, будуються додаткові ключі, які використовують для формування поштового штемпелю. У поштовому центрі подібним чином генеруються додаткові ключі, які використовуються для перевірки поштових штемпелів. [У патенті США 5 150 408] описано спосіб розподілення ключів у системі зв'язку, наприклад, безпровідній мережі, коли шифроване повідомлення передається до пристрою зв'язку вузлом розподілення ключів. Після прийому цього повідомлення пристрій зв'язку надсилає підтвердження до вузла розподілення ключів. Існує стандарт ANSI X9.17 передачі шифрованих даних [див. URL http://csrc.nist.gov/publications/nidtpubs/800 7/node209.htm від 7/10/1994], який базується на ієрархії серед декількох ключів. Тут існує щонайменше один ключ даних короткої тривалості, обмін яким електронним шляхом у зашифрованій формі здійснюється між партнерами зв'язку, як це відбувається також і з ключем для шифрування ключа даних, обмін яким здійснюється вручну. У даному документі описано відомий спосіб ДифіГелмана (Diffie-Hellman) шифрування даних, згідно з яким партнери зв'язку обчислюють спільний ключ з відомих чисел і з секретного випадкового числа. [В Європейському патенті EP 0 735 722 А2] описано систему розпорядження ключами для генерування, розподілення ι контролю ключів для франкувальних машин. Тут існують декілька убезпечених зон, з'єднаних з комп'ютерами, які дозволяють здійснювати зв'язок між зонами і контроль цих зон. Кожна з операцій генерування ключів, їх встановлення, верифікації і підтвердження виконується в одній з цих зон Кожна зона має зв'язок з архівом, в якому протоколюється статус зони. Задачею винаходу є створення способу швидкої і надійної верифікації аутентичності поштового штемпелю. Зокрема, цей спосіб має бути придатний для широкого застосування у процедурах верифікації, у першу чергу у поштових або вантажних центрах. Згідно з винаходом, цю задачу вирішено, як це визначено у п.1 Формули винаходу. Зокрема спосіб верифікації аутентичності реалізується таким чином, що ключ даних генерується і передається центральною базою даних (центральна система ZinS) до локальних систем убезпечення платежів (локальна ZinS). Це здійснюється шляхом використання генерованого франкувального ключа і поштового штемпелю, застосованих до поштової кореспонденції, завдяки чому криптографічна інформація, що міститься у поштовому штемпелі, дешифрується і використовується для верифікації аутентичності цього поштового штемпелю. Для підвищення безпечності способу доцільно, щоб локальна система убезпечення платежів імпортувала ключ даних і передавала результат імпортування до центральної бази даних (центральної системи ZinS). У найбільш бажаному втіленні винаходу результат імпортування передається у вигляді запису даних. Бажано, щоб запис даних містив ключ. Цей ключ може мати різні атрибути. Зокрема, він може бути симетричним або асиметричним ключем. Залежно від призначення ключ слугує для дешифр ування і/або шифрування інформації. За своєю природою ключ може також переносити інфо 5 рмацію. Наприклад, ключ може містити інформацію про франкувальний ключ і дату його генерування і/або закінчення дійсності. Для забезпечення однорідного обміну ключами доцільно, щоб центральна база даних (центральна система ZinS) перевіряла результат імпортування і передавала його до центру передачі вартостей (Поштового П ункту). Це втілення винаходу уможливлює виконання у центрі передачі вартостей такої подальшої операції процесу, як визначення результату імпортування. Результат можна перевіряти різними шляхами. Однак, це найкраще робити дешифруванням ключа. Бажане втілення винаходу характеризується тим, що після успішного імпортування ключа даних майже в усі локальні системи убезпечення платежів (локальні ZinS) ключ даних вивільняється як новий франкувальний ключ у центрі передачі вартостей (Поштовому Пункті) і у подальшому використовується для формування нового поштового штемпелю. Це втілення способу дозволяє виконувати заміну ключів у центрі передачі вартостей як функцію попередніх замін ключів у системах убезпечення платежів. Цим забезпечується те, що поштовий штемпель буде сформований лише з використанням нового ключа, якщо цей новий ключ вже є у локальних системах убезпечення платежів. Цим забезпечується можливість верифікації дійсності кожного сформованого поштового штемпелю локальною системою убезпечення платежів. Бажане втілення способу згідно з винаходом з застосуванням контролю заміни ключів у центрі передачі вартостей як функції заміни ключів у локальній системі убезпечення платежів є особливо зручним у сполученні з щонайменше однією з інших операцій процесу. Зокрема, сполучення декількох операцій забезпечує швидкий і надійний обмін ключами з верифікацією кожного обміну. При заміні ключів доцільно передавати нові ключі даних від центра передачі вартостей (Поштового П ункту) до центральної системи убезпечення платежів. Особливо зручно шифрувати ключ даних транспортним ключем (TK) у центрі передачі вартостей. Доцільно шифрувати транспортний ключ головним транспортним ключем (ГТМ). Бажано генерувати ключ даних у зоні центра передачі вартостей. Цим виключаються шахрайські заміни ключів даних під час їх передачі до центра передачі вартостей. Для додаткового підвищення захисту даних доцільно забезпечувати ключ даних ідентифікаційною інформацією про ключ. Бажано передавати цю ідентифікаційну інформацію у зашифрованій формі. Щоб забезпечити використання дійсного ключа даних у кожній з операцій шифрування і/або дешифр ування, бажано додавати до ключа даних лічильник генерувань і передавати його з цим лічильником. 84861 6 Щоб уникнути використання недійсних ключів, бажано додавати до франкувального ключа кінцеву дату попереднього ключа даних і/або передавати його разом з цією кінцевою датою. Описаний ключ даних можна використовувати для однієї або більше часткових верифікацій, а також для формування поштового штемпелю і/або для дешифрування інформації, що міститься у цьому штемпелі. Бажано, щоб часткова верифікація включала дешифр ування криптографічної інформації, що міститься у поштовому штемпелі. Інтегрування дешифрування криптографічної інформації у процес верифікації дозволяє безпосередньо підтвердити аутентичність поштового штемпелю, завдяки чому верифікацію можна проводити у реальному часі. Крім того, бажано, щоб одна з часткових верифікацій включала порівняння між поточною датою і датою формування поштового штемпелю. Додання дати формування поштового штемпелю, особливо у ши фрованій формі, підвищує захищеність даних, оскільки порівняння між поточною датою і датою формування поштового штемпелю відвертає багаторазове використання поштового штемпелю. Для підвищення швидкості верифікації бажано, щоб вузол зчитування і вузол верифікації обмінювались інформацією з застосуванням синхронного протоколу. В іншому бажаному втіленні винаходу вузол зчитування і вузол верифікації має зв'язок з застосуванням асинхронного протоколу. Особливо зручно телеграфувати дані від вузла зчитування до вузла верифікації. Інші переваги, особливі ознаки і практичні удосконалення визначено у залежних п.п.Формули і розглядаються у наведеному нижче описі з посиланнями на креслення, в яких: Фіг.1 - бажане втілення розподілення ключів згідно з винаходом, Фіг.2 - варіанти застосування розподілення ключів згідно з винаходом, Фіг.3 - схема інтерфейсу між центральною системою убезпечення платежів (центральною ZinS) і центром передачі вартостей (Поштовим Пунктом), Фіг.4 - операції процесу інтегрування ключа даних у центральну систему убезпечення платежів (центральну ZinS), Фіг.5 - схема розподілення ключів від центральної системи убезпечення платежів (центральної ZinS) до локальних систем убезпечення платежів, включаючи компетентні криптосистеми, Фіг.6 - зв'язок з інтерфейсом DDL, Фіг.7 - схема операцій процесу інкапсуляції компонентів і обробки хибних повідомлень. Далі наведено опис винаходу з посиланням на систему франкування PC. Операції убезпечення платежів є незалежними від системи формування поштових штемпелів. Особливо бажаною є децентралізована верифікація на індивідуальних верифікаційних станціях, зокрема, у поштових центрах, але припустимою є також централізована верифікація. 7 У бажаному втіленні винаходу індивідуальними верифікаційними станціями є локальні системи убезпечення платежів, з'єднані, бажано, з центральною системою убезпечення платежів зв'язком для передачі даних. В іншому втіленні центральною системою убезпечення платежів (центральною ZmS) є Поштовий П ункт. Інтерфейс між центром передачі вартостей і системою убезпечення платежів складається з криптографічних ключів. Ключ, яким мають обмінюватись центр передачі вартостей і система убезпечення платежів, забезпечує захист поштового штемпелю від підробки. Це досягається тим, що частина штри хкоду 2D, який утворює поштовий штемпель, зашифровується зазначеним ключем. Оскільки з технологічних міркувань вибраний ключ є симетричним, він має бути переданий від центра передачі вартостей до системи убезпечення платежів, де він розподіляється між індивідуальними поштовими центрами. Надійне зберігання ключів забезпечується використанням спеціальних криптокарт. Винахід включає декілька застосувань, в яких ці ключі використовуються з застосуванням спеціальних технічних засобів. Повний життєвий цикл цих ключів - генерування, експорт, розподілення і нарешті імпорт у децентралізовану систему - є необхідним для оптимізації параметрів системи. Фіг 1 ілюструє бажану послідовність для розподілення ключів, а саме, бажане розподілення між центром передачі вартостей і центральною системою убезпечення платежів. Першою операцією 1 заміни франкувального ключа, призначеного для формування поштового штемпелю, є генерування нового франкувального ключа. Термін "франкувальний ключ" тут не слід розуміти в обмежувальному сенсі, оскільки він може бути використаний багатьма шляхами для формування поштового штемпелю. Наприклад, франкувальний ключ можна використовувати для формування поштового штемпелю безпосередньо. Є можливим і бажаним, однак, у системах підвищеної захищеності проти маніпуляцій формувати поштовий штемпель з мультишифрованим вмістом даних, причому цей вміст бажано формувати якрезультат декількох операцій в одному або декількох місцях і вводити результат операції у поштовий штемпель франкувальним ключем. Наприклад, у франкувальний ключ вводять крипторядок типу, описаного у [DE 100 20 402 А1]. Для подальшого захисту проти ша храйського виготовлення поштових штемпелів застосовується заміна франкувального ключем, специфічна для певного місця. У даному випадку франкувальний ключ наново генерують з регулярним інтервалом, наприклад, після закінчення заздалегідь визначеного інтервалу часу. Можна також виконувати нове генерування франкувального ключа як функцію інших параме 84861 8 трів, наприклад, на основі завантаженої суми поштових зборів і/або франкованих поштови х кореспонденцій. Взагалі нове генерування нового франкувального ключа можна виконувати у будь-якому місці, однак, для кращої безпеки бажано мінімізувати дії, пов'язані з передачею нового франкувального ключа і генерувати його у центрі передачі вартостей або у зоні цього центра. Для забезпечення високого рівня захисту проти шахрайства бажано дешифрувати інформацію з поштового штемпелю на основі франкувального ключа у зоні локальної системи убезпечення платежів, наприклад, у поштови х або вантажних центрах. Для цього франкувальні ключі передають з центра передачі вартостей до центральної системи убезпечення платежів, бажано, автоматично. Заміну бажано виконувати через сервер центральної системи убезпечення платежів (центральної ZinS). Центр передачі вартостей (Поштовий Пункт) можна не конфігур ува ти. Оскільки сервер не повинен знати центр передачі вартостей (локальних систем ZinS) і його відповідні криптосистеми, для зазначеного сервера важливим є лише центральний сервер ZinS. Після нового генерування бажаного симетричного франкувального ключа його з захистом передають до центральної системи убезпечення платежів (опер.2 Фіг.1) і розподіляють звідси до криптосистем, розташованих у локальних системах убезпечення платежів (опер.3). Ці системи повертають результат імпортування (опер.4) і цим підтверджують успішне імпортування ключа. Результат компілюється центральною системою, підтверджується і передається до центра передачі вартостей (Поштового Пункту) (опер.5). Після успішного імпортування ключа в усі криптосистеми він вивільняється у центрі передачі вартостей (Поштовому Пункті) і далі використовується для генерування нових поштових значень (опер.6). Симетричні ключі є бажаними і є складовою частиною захисту від шахрайства поштови х штемпелів, сформованих з використанням франкувального ключа, завдяки чому зазначені поштові штемпелі мають, наприклад, форму двомірних штри х-кодів. Отже, обмін цими ключами має бути захищений сильною криптографією. Для забезпечення цього важливо виконати такі вимоги: - Конфіденційність вмісту: необхідно забезпечити неможливість зчитування переданих ключів третіми особами під час передачі. Крім того, необхідно забезпечити безпечне зберігання ключів. Це досягається застосуванням криптокарт WebSentry. - Цілісність вмісту: неможливість підробки частин ключа третіми особами. - Аутентифікація: обидва партнери, що мають зв'язок, мають бути впевнені, що ідентичність передавача/реципієнта є правильною. З точки зору реципієнта це означає, що ключ має бути генерований Поштовим Пунктом. З точки зору передавача має існувати гарантія, що приймати 9 ключ дозволено лише дійсним локальним криптосистемам ZinS. У цьому симетричному варіанті обидва партнери мають однаковий ключ TК. Центр передачі вартостей (Поштовий Пункт) використовує ключ TК для шифр ування ключа даних (КД), що має бути переданий, і потім передає зазначений ключ даних до сервера центральної системи убезпечення платежів (ZinS). З центральної системи убезпечення платежів цей ключ розподіляється до локальних криптосистем ZinS локальної системи убезпечення платежів. Ці системи також мають доступ до ключа TК і можуть щонайменше один раз дешифрувати ключ даних. Оскільки ключ TК використовується для захисту ключа даних під час транспортування, його називають транспортним ключем. Оскільки всі локальні системи убезпечення платежів приймають однакові дані, нема необхідності визначати окремий транспортний ключ між кожним локальним криптосервером і центром передачі вартостей (Поштовим Пунктом). З міркувань безпеки, однак, цей ключ необхідно оновлювати, як і ключ даних, з регулярним інтервалом. Але, оскільки текст, який шифрується цим ключем, не такий великий, як текст, що шифр ується ключем даних, інтервал між обмінами може бути збільшений. Бажаний інтервал становить 12 роки. Суттєвим компонентом такого рішення є заміна транспортних ключів, яке з міркувань безпеки не слід здійснювати через канал обміну ключем даних. Ця заміна не виконується вручну. Оскільки цю процедуру необхідно виконувати з регулярним інтервалом для декількох локальних систем убезпечення платежів, має бути застосований метод автоматичної заміни транспортних ключів. Для цього стандарт ANSI X9.17 (Розпорядження ключами на основі симетричних методів) визначає інший рівень ключів, а саме, головний транспортний ключ (ГТК). Цей ключ встановлюють у криптокарті з спеціальними заходами безпеки і і в подальшому він має застосовуватись зі значними інтервалами. У даному випадку в усі х системах встановлюють однаковий ГТК. Цей ключ шифрує транспортні ключі, які потім розподіляються і імпортуються автоматично через той же канал. Розподілення здійснюється, як і для ключів даних. Ініціалізація індивідуальних систем або їх криптокарт розглядається нижче. Для забезпечення цілісності повідомлення і аутенти фікації передавача (Поштовий Пункт) формується матричний код (MК) для індивідуальних ключових повідомлень. Для генерування MК необхідно мати сигнатурний ключ (CК), який, як і ГТК, імпортується під час ініціалізації криптокарти. Ключем CК надається сигнатура для ключів даних. Цим ефективним криптографічним методом забезпечується конфіденційність інформації при передачі повідомлень у системі Intranet для Deutche Post. Для шифр ування і дешифр ування повідомлень бажано застосовувати ключ Triple DES (довжина 168 байт). Хеш-значення бажано обчислювати, використовуючи алгоритм SHA-1. 84861 10 При розподіленні і зберіганні ключів даних слід брати до уваги різні періоди дійсності у Поштовому П ункті і у криптосистемах систем убезпечення платежів. У будь-який момент у Поштовому Пункті мають бути доступними не більше двох ключів даних, а саме, один ключ з поточною дійсністю і ще один для ши фрування щойно генерованих сум поштови х зборів (КДнов). У режимі "заміни" існуючого ключа ключем КДнов новий ключ передається до криптосистем систем убезпечення платежів. Після успішного імпортування цього ключа всіма криптосистемами локальних систем убезпечення платежів генерується повідомлення центральної системи ZinS про вивільнення і у цей момент КДнов використовується для шифрування нових сум поштових зборів у Поштовому Пункті. У цей момент старий ключ даних має бути стертий у Поштовому Пункті і більше не використовуватись для генерування нових сум поштових зборів. Ситуація з криптосистемами локальних систем убезпечення платежів є іншою' оскільки завантажена сума поштових зборів може бути потрібною протягом невизначеного періоду, наприклад, трьох місяців, для формування поштови х штемпелів необхідно мати декілька ключів даних для їх верифікації. Коли справа доходить до розподілення ключів, слід брати до уваги долю ключів, які не можуть бути імпортовані у деякі криптосистеми і тому не можуть бути активовані у Поштовому Пункті. Можливо, ці ключі були імпортовані в інші криптосистеми і, у принципі, мають бути ураховані там під час майбутніх верифікацій. Для забезпечення однакових умов, що дозволяє чітку версифікацію ключів і спрощує обслуговування системи, бажано забезпечити такі форми реалізації способу розподілення ключа: а) Ключі даних передаються у шифрованій формі з однозначним ключем ID (індикатор фази ключа), невизначеним лічильником генерувань і кінцевою датою дійсності попереднього ключа даних. Лічильник генерувань використовується, щоб відрізняти багаторазові хибні спроби завантаження бажаних оновлень симетричних ключів даних (забезпечення безпеки транзакцій, див. g)). b) Кожна передача ключа даних від центра передачі вартостей (Поштового Пункту) має бути підтверджена центральною системою убезпечення платежів підтверджуючим повідомленням. c) Якщо підтвердження є позитивним, це означає, що ключ даних був успішно встановлений в усіх локальних системах убезпечення платежів і може бути наданий клієнтам з використанням франкування PC. У цьому випадку лічильник генерувань інкрементується одиницею для передачі наступного ключа даних. d) Якщо підтвердження є негативним, це означає, що ключ даних не був успішно встановлений в усіх локальних системах убезпечення платежів і не може бути наданий центром передачі вартостей (Поштовим Пунктом) системам клієнтів для формування поштових штемпелів, оскільки існує ризик масових хибних відправлень 11 цінної поштової кореспонденції. У цьому випадку лічильних генерувань не інкрементується і залишається з значенням попередньої передачі. e) Якщо підтвердження відсутнє, центр передачі вартостей (Поштовий Пункт) не може почати подальшої передачі ключа до центральної системи убезпечення платежів (центральної ZinS) (такі спроби будуть ігноровані системою убезпечення платежів і мають бути блоковані у центрі передачі вартостей). f) Якщо підтвердження системою убезпечення платежів залишається відсутнім протягом тривалого часу (довше зумовленої часової затримки), центр передачі вартостей (Поштовий Пункт) може ініціювати тривожне повідомлення через свої прямі або непрямі користувацькі інтерфейси. g) Негайно після прийому ключа даних криптокартою, вона стирає всі ключі даних, які мають значення лічильника генерувань, яке відповідає останній передачі. Завдяки цьому у випадку багаторазових пов'язаних з помилками передач ключі, що раніше могли бути успішно завантажені у деякі криптокарти, зникають. Цим захищається передача ключів. h) У криптокартах локальних систем убезпечення платежів багаторазово, бажано, регулярно, найкраще щоденно, ініціюється програма стирання ключів даних, в яких зникла потреба. Ключ даних стирається, коли кінцева дата, збережена для наступного ключа даних в атрибуті CКA_END_DATE є меншою за поточну системну дату. і) Щодо кінцевої дати попереднього ключа, має бути запланований додатковий період (найкоротший з можливих), оскільки поштовий штемпель, сформований з сумою поштових зборів, яка втратила дійсність, вважається дійсним протягом ще двох днів після закінчення терміну дійсності при його перевірці у зоні локальної системи убезпечення платежів Крім того, має бути урахований час, що проходить між формуванням і вивільненням нового ключа даних. Фіг.2 ілюструє варіанти застосування керування ключами згідно з винаходом і його використання у зоні системи убезпечення платежів. Показані також зони застосування. Далі розглядаються варіанти застосування, зокрема, деталі описаного розпорядження ключами. Застосування розглядається на прикладах використання криптокарт. Перш за все розглядається ініціалізація криптокарт у зоні центра передачі вартостей (Поштового Пункту): - Встановлення і конфігурування карти, завантаження "зашитих" програм карти, якщо цього не зробив виробник. Функції "зашитих" програм карти розширюються вбудованим кодом (власні процедури) і, для захисту узгоджені з PKCS 11 (Стандарти криптографії публічних ключів) процедури роботи з ключами (генерування, стирання тощо) мають бути блоковані для користувача. Цим підвищується захист ключа. 84861 12 - Визначення кластерів (з декількома криптокартами). - Генерування і зберігання локального головного ключа (ЛГК), який підлягає розподіленню на щонайменше три компоненти, два з яких є особливо потрібними для відновлення щойно ініціалізованих криптосерверних карт. Бажано записувати кожний з компонентів у смарт-карту з захистом персонального коду, завдяки чому адміністратори безпеки отримують смарт-карти. Крім того, необхідно виготовити запасні смарт-карти. У подальшому ЛГК слугує як MTK. - Користувацька адміністрація: стирання адміністратора безпеки за замовчування і визначення адміністратора безпеки з включенням правил аутенти фікації реквізитів (на основі смарткарти) - Генерування початкового сигнатурного ключа (CK), шифрування (згортання) ГТК і зберігання як файлу. Копіювання цього файлу на дискету (доступ до файлів/дискет має лише адміністратор безпеки). - Генерування першого TK, створення належного ключового повідомлення у файлі і копіювання цього файлу на дискету (доступ до файлів/дискет має лише адміністратор безпеки). Генерування MTK Нові MTK бажано генерувати, як це описано нижче. Локальний головний ключ (ЛГК) належної конфірмаційної карти слугує як ГТК. З міркувань безпеки ЛГК розділяють на щонайменше три компоненти, з яких щонайменше два з них є необхідними для реімпортування. Індивідуальні компоненти зберігаються у смарт-картах і захищені індивідуальними кодами (PIN), причому кожний адміністратор безпеки отримує смарт-карту і захищає її власним PIN. Зберігання смарт-карт у безпечному місці і секретність PIN виключає доступ до них сторонніх осіб. Для користування ГТК бажано використовувати щонайменше два компоненти ГТК, які відповідають двом різним авторизованим картам, завдяки чому автоматично витримується принцип подвійного контролю. ГТК має бути ключем типу Triple DES. Атрибут ID ключа складається з ідентифікатора типу і унікального номера. Ідентифікатор типу: TК Унікальний номер: від 01 до 99 Довжина: фіксовані 4 байти у файлі CK_CHAR. Для забезпечення доступу до обміну ключами лише авторизованих осіб можна застосовувати різні механізми захисту. В описаному нижче втіленні використано сигнатурні ключі, що є особливо зручним, оскільки забезпечує особливо надійний захист від маніпуляцій. Сигнатурний ключ (CК) забезпечує захищеність цілісності ключових повідомлень. Його можна також використовувати перед імпортом ключа для перевірки, чи є передавачем Поштовий Пункт Генерування CК може виконувати лише адміністратор безпеки, зареєстрований через смарткарту. Це має бути ключ TDES з значенням атрибутом захисту "чутливий" TRUE і атрибутом "ви 13 84861 добування" FALSE для запобігання виявлення тексту ключа назовні смарт-карти. Атрибут ID ключа складається з ідентифікатора типу і унікального номера. Ідентифікатор типу: CК Унікальний номер: від 01 до 99 Довжина: фіксовані 4 байти у файлі CK_CHAR. Атрибут ключа CКA_ID CКA_LABEL CКA_START_DATE CКA_END_DATE CКA_SENSITIVE CКA_EXTRACTABLE CКA_ENCRYPT CКA_DECRYPT 14 Для експортування ключа він має бути згорнутий ключем ГТК і збережений як файл на дискеті, яку необхідно зберігати у безпечному місці і використовува ти для ініціалізації криптосерверних карт. Цілісність файлу ключа забезпечується програмою обробки, що знаходиться у карті і використовується для згортання. Наведена нижче таблиця містить бажані атрибути CK ключа TK. Атрибути CK транспортного ключа Значення CK+ порядковий унікальний номер (від KS01 до KS99) для унікального призначення ключа Не заповнюється; відповідає схемному значенню за замовчування у момент генерування Дата, від якої ключ вважається дійсним, у форматі PKCS 11 (встановлюється адміністратором безпеки Дата, після якої попередній ключ має бути стертий TRUE FALSE TRUE TRUE Рандомізоване число в атрибуті LABEL слугує для підтвердження успішного імпортування у криптосерверні карти. Для цього випадкового числа формується хеш-значення (наприклад, засобами SHA-1) і використовується для підтвердження успішного імпортування, а також вивільнення ключа. Атрибути CКA_ID і CКA_LABEL заповнюються як CК_CHAR. Всі подальші атрибути визначаються як типи через файл pkcsi 11.h. Сигнатурний ключ шифрується ключем ГТК (=ЛГК, механізм CKM_KEY_WRAP_WEBSENTR Y) і завантажується у схему на місці як ЛГК. Нижче розглядається генерування TK. У цьому варіанті застосування генерується TK, який включає належне ключове повідомлення. Бажано, щоб конфігурація модуля генерування ключа забезпечувала генерування TК і ініціалізацію належного ключового повідомлення лише адміністратором безпеки. Інтервал між замінами має становити 1-2 роки TК є ключем типу TDES з такими атрибутами: Атрибути TK Значення TK + порядковий унікальний номер (від КТ01 до КТ99) для унікального призначення ключа CКA_LABEL Випадкове значення довжиною 64 байти, яке генерується методом C GenerateRandom PKCS 11 CКA_START_DATE Дата, від якої ключ вважається дійсним, у форматі PKCS 11 (встановлюється адміністратором безпеки) CКA_END_DATE Дата, після якої попередній ключ має бути стертий CКA_SENSITIVE TRUE CКA_EXTRACTABLЕ FALSE CКA_ENCRYPT TRUE CКA_DECRYPT TRUE Атрибут ключа CКA_ID Рандомізоване число в атрибуті LABEL слугує для підтвердження успішного імпортування у криптосерверні карти. Для цього випадкового числа формується хеш-значення (наприклад, засобами SHA-1) і використовується для підтвердження успішного імпортування, а також вивільнення ключа. Атрибути CКA_ID і CКA_LABEL заповнюються як CК_CHAR. Всі подальші атрибути визначаються як типи через файл pkcsi 11.h. TK шифр ується ключем ГТК (=ЛГК, механізм CKM_KEY_WR AP_WEBSENTR Y) і для передачі від центра передачі вартостей (Поштового Пункту) до центральної системи убезпечення платежів формується така структура: 15 1 Довжина 2 №№ байт f1-f4 2 1 f3 3 4 5 4 4 n-13 f4-f8 f9-f12 f13-fn1 6 24 fn+1-f n+24 П.п. 84861 Призначення №№ байт f1-f4 Опис MsgTYpe Ідентифікатор ключового повідомлення, константа "КT" Версія структури повідомлення, 1 байт, що починається з значення "01" KeylD Ідентифікатор TК прямим текстом SigKeylD Ідентифікатор ключа, що використовується для сигнатури TranspKeyEncrypt Результат ши фрування (згортання) TК MК для ключового повідомлення; формується як хеш-значення SHA-1 для полів 1-5 повідомлення, причому це значення шифруMAC ється сигнатурним ключем (механізм CKM_DES3_CBC_PAD, IV заповнюється нулями, ID - див. поле f3. Version Після подальшого розподілення це повідомлення TК передається до центрального сервера ZinS. Інтерфейс - типу Session Bean, це обслуговування виявляють з використанням сервісу найменувань (Java Naming and Directory Interface JNDI). Спосіб транспортування має ураховувати наведений вище блок даних. Це повідомлення зберігається у Поштовому Пункті як файл, і адміністратор безпеки може потім зберігати його на одній або декількох дискетах у безпечному місці. У подальшому ці дискети використовуються для ініціалізації нових криптосерверних карт. Π.п. Довжина 1 4 16 Призначення KeylD Далі розглядається бажане втілення процедури вивільнення TК Конфігурація центра передачі вартостей дозволяє вивільняти TК. Для цього існує інтерфейс, через який центр передачі вартостей може вивільняти цей TК, як тільки він був успішно розподілений і імпортований в усі системи убезпечення платежів (криптосистеми ZinS). Лише через вивільнення можна використовувати належний TК для шифр ування ключів даних. Інтерфейс реалізований як Session Bean. Це обслуговування виявляють з використанням сервісу найменувань. Бажана структура даних для процедури вивільнення має такі параметри: Опис Ідентифікатор TК прямим текстом. 2 201 f4-f24 RandomHash Хеш-значення SHA-1 рандомізованого числа переноситься як атрибут LABEL TK. Результат шифр ування: TRUE= є необхідною обробка: вивільнення мож3 1 f25 State ливе, FALSE= обробка не була успішною. Детальне повідомлення про причину помилки або детальне повідомлення 4 128 f26-f153 Message про успіх. Далі розглядається приклад генерування ноАутентифікація призначення ключа системи вих ключів даних. убезпечення платежів (система KеуМаn-agement У даному випадку генерується ключ даних з ZinS) vis-à-vis PP KeyManagement system виконуналежним ключовим повідомленням. Бажано, ється з використанням параметра 2, тобто хе шщоб система призначення ключів мала конфігузначення, отриманого методом SHA-1 з атрибута рацію, яка дозволяє ініціювання цієї дії лише адLABEL TК. Цей атрибут заповнюють випадковим міністратору безпеки. Це необхідно проводити значенням під час генерування TК. Оскільки TК і кожні 3 місяці. Якщо ключ даних є в обігу і для всі його атрибути ши фруються під час передачі, нього від центральної системи убезпечення плалише криптосервер ZinS може обчислити правитежів (центральної системи ZinS) ще не було льне хеш-значення. отримано зворотного зв'язку (вивільнення або Якщо передане хеш-значення є ідентичним помилка), генерування нових ключів даних блохеш-значенню TК, обчисленого для атрибута кується до отримання зворотного зв'язку. LABEL, і це хе ш-значення знаходиться у модулі Ключ даних використовується для шифр уWebSentry Поштового Центра, а переданий ставання вмісту певного матричного коду і для затус обробки є TRUE, то TК активується. безпечення того, щоб жоден поштовий штемпель Це означає, що у подальшому повідомлення не був сформований, якщо не було зроблено ключа даних шифр уватимуться TК. жодного платежу провайдеру поштових послуг. Цей варіант застосування може існувати, якЦей ключ даних слугує для верифікації цифровощо обробка є хибною (переданий статус го поштового штемпелю у криптосерверах ZinS. FALSE). У цьому випадку статус для цього генеКлючі даних також є ключами TDES, що генерурування ключа і його розподілення протоколюються з використанням функції C_GenerateKey, і ється і відповідний TК стирається. мають такі атрибути: 17 84861 18 Атрибути ключа даних Значення Порядковий унікальний номер (наприклад, 01) для унікального призначення ключа (без префіксу); відповідає індикатору фази ключа, який закодовано у поштовому штемпелі і у PostagelD. CКA-LABEL 1-й байт: лічильних генерувань для спрощеного стирання ключів у криптосистемах ZinS, які не можна активува ти. Байти 2-65: випадкове значення довжиною 64 байти, яке генерується методом C_GenerateRandom PKCS 11. CКA_START_DATE Дата, від якої ключ вважається дійсним, у форматі PKCS 11 (встановлюється адміністратором безпеки) CКA_END_DATE Вказує не дату кінця терміну дійсності ключа, а дату кінця дійсності попередника, тобто дату, після якої попередній ключ має бути стертий. CКA_SENSITIVE TRUE CКA_EXTRACTABLE FALSE CКA_ENCRYPT TRUE CКA_DECRYPT TRUE Атрибут ключа CКA_ID Значення для атрибута CКA_ID встановлюється системою. CКA_ID завжди інкремен-тується одиницею, а лічильник генерувань інкрементується лише у випадках успішного вивільнення. Атрибути CКA_ID і CКA_LABEL заповнюються як CК_CHAR. Типи подальших атрибуті в визначаються через файл pkcs.h. Рандомізоване число в атрибуті LABEL слугує для підтвердження успішного імпортування у криптосерверні карти. Для цього числа формується хеш-значення (засобами SHA-1) і воно ви користовується для підтвердження успішного імпортування і вивільнення TК. Генерування повідомлення для заміни ключа даних є де що складнішим і складається з таких дій: 1. Ключ даних шифр ують ГТК (=ПГК, механізм CKM_KEY_WRAP_WEBSENTR Y). Це дає ту перевагу, що всі атрибути (між іншими, CКA_EXTRACTABLE=FALSE) шифр уються і їх значення відновлюються під час дешифрування. Цією байтовою послідовністю репрезентується проміжне повідомлення такої структури: Структура проміжного повідомлення для ключа даних П.п. Дов- №№ жина байт 1 n f1-n Призначення Опис DateKeyEncrypt Результат шифр ування (згортання) ключа даних спеціальним механізмом WebSentry (ГТК) 2. Проміжне повідомлення у свою чергу шифр ується активним TК з використанням механізму CKM_DES3_CBC_PAD (вектор IV ініціалізації заповнюється нулями). 3. Формується повідомлення, що підлягає розподіленню і має таку стр уктур у: П.п. 1 2 3 4 5 6 7 8 Структура повідомлення для ключа даних, призначеного для розподілення Дов- №№ Призначення Опис жина байт 2 f1-f4 MsgTYpe Ідентифікатор ключового повідомлення, константа "КT" 1 f3 Version Версія структури повідомлення, 1 байт, що починається з значення "01" 1 f4 Key ID Ідентифікатор TК у прямому тексті 2 f5-f7 KeyGeneration Лічильник генерувань прямим текстом, наприклад, "01" 4 f8-f12 SigKeylD Ідентифікатор ключа, застосованого до сигнатури f12Ідентифікатор TК, застосованого для шифрування проміжного повідом4 KTID f16 лення η f16-fns HelperMsgEncrypt Результат ши фрування проміжного повідомлення МАС для проміжного повідомлення формується як хеш-значення SHA-1 fn1+1для поля 7 повідомлення і це хеш-значення шифрується сигнатурним 24 f MAC n1+24 ключем (механізм CKM_DES3_CBC_PAD, IV заповнюється нулями, ID див. поле 5). 4. Далі повідомлення ключа даних передається для розподілення до центрального сервера ZinS. Воно зберігається адміністратором безпеки на одній або декількох дискетах у безпечному місці. У подальшому ці дискети використовуються для ініціалізації нових крипто-серверних карт. Перевагою подвійного шифрування вмісту повідомлення є зменшення шифру, що має бути переданий до ГТК через Інтранет, і ускладнення криптоаналізу цього ключа. Для вивільнення ключа даних застосовується інтерфейс і протокольний механізм, які забезпе 19 84861 чують протоколювання вивільнення ключа Центральна система убезпечення платежів бажано конфігур увати таким чином, щоб ключ даних вивільнявся лише після успішного розподілення і успішного імпортування цього ключа у криптосистеми локальних систем убезпечення платежів. Лише завдяки цьому вивільненню належний ключ даних у подальшому успішно використовується для шифрування крипторядків, що мають бути введені у поштовий штемпель, після чого ідентифікаційна інформація KеуID ключа Π.п. Дов- №№ жина байт 1 1 f1 20 кодується у ідентифікаційну інформацію (PostagelD) поштових платежів. Інтерфейс, реалізований через CWMS (комп'ютеризована робоча система менеджменту), діє між центральною системою убезпечення платежів (центральна ZinS) і локальними системами убезпечення платежів (локальні ZinS). Центр передачі вартостей (Поштовий Пункт) 33 приймає інформацію через відповідний вхід, Структура даних для процедури вивільнення має вигляд: Призначення Опис Key ID Ідентифікатор TК прямим текстом. Хеш-значення SHA-1 рандомізованого числа переноситься як атрибут LABEL ключа даних. Результат шифр ування: TRUE - успішна обробка: вивільнення можливе, FALSE - обробка не була успішною. Детальне повідомлення про причину помилки або детальне повідомлення про успіх. 2 20 f2-f22 RandomHash 3 1 f23 State 4 128 f23f151 Message Аутентифікація системи призначення ключів системи убезпечення платежів відносно системи системи призначення ключів центра передачі вартостей (Поштового Пункту) виконується через параметр 2. Бажано, щоб це було хеш-значення, яке з застосуванням метода SHA-1 формується з атрибута LABEL ключа даних. Атрибут L ABEL заповнюється рандомізованим числом під час генерування ключа даних. Оскільки ключ даних і всі його атрибути ши фруються під час передачі, лише криптосервер системи убезпечення платежів може обчислити правильне хеш-значення. Якщо передане хеш-значення є ідентичним хеш-значенню ключа даних, обчисленого для атрибута LABEL , і це хе ш-значення знаходиться у модулі WebSentry Поштового Центра, а переданий статус обробки є TRUE, то ключ даних активується. Це означає, що у подальшому крипторядки для поштових штемпелів/поштових платежів шифр уватимуться цим ключем даних. Цей варіант застосування може існувати, якщо обробка є хибною (переданий статус FALSE). У цьому випадку статус для цього генерування ключа і його розподілення протоколюється і відповідний ключ даних на карті стирається, а лічильник генерувань не інкрементується. Бажано, щоб система призначення ключів мала статусну пам'ять для зберігання виконаних генерувань ключа. Поки не одержано зворотного зв'язку від центральної системи убезпечення платежів (центральної системи ZinS) про виконане розподілення ключа, статус репрезентується як відкритий. Після отримання успішного зворотного зв'язку і розподілення, ключ призначається як активований. У випадку помилки надається передане повідомлення про статус. При наявності помилок або тривалій відсутності повідомлення про вивільнення виконується програма аналізу помилки. Бажано виконувати архівування ключів. Бажаний варіант архівування ключів у зоні центра передачі вартостей (Поштового Пункту) розглядається нижче. Для захисту ключів архіватор мо же ініціювати функцію архівування, яка шифрує всі ключі (за винятком ГТК) ключем ГТК (механізм CKM_KEY_WR AP_WEBSENTR Y) і повертає їх. Ці ключі слід зберігати у базі даних або у захищеній зоні файлової системи. Після успішного архівування стираються всі ключі, для яких початковий термін дійсності минув більш, ніж 6 місяців тому, і які не є активними. Ключі відновлюються, зокрема у зоні центра передачі вартостей (Поштового Пункту), тобто архівовані дані ключа дешифруються (розгортаються) знову і зберігаються у карті. Для цього знову використовується механізм CKM_KEY_WR AP_WEBSENTR Y. Після дешифрування ключа ключ з такою ж ідентифікаційною інформацією KеуID, який вже є у карті, стирається. Завдяки спеціальним заходам безпеки у карті WebSentry і розподіленню між декількома смарт-картами, ГТК надійно захи щений проти втр учання. Якщо необхідно замінити ГТК, то, як у випадку ініціалізації криптокарти (ПП), мають бути генеровані нові сигнатурні ключі, транспортні ключі і ключі даних. Попередній ГТК залишається у карті як так званий "бездіяльний ключ" і має бути стертий адміністратором безпеки. Далі розглядаються бажані варіанти застосування системи призначення ключів в усіх згідно з одним з аспектів системи убезпечення платежів. Це дає особливі переваги, коли індивідуальні компоненти застосовуються, бажано, у зоні локальної системи убезпечення платежів або центральної системи убезпечення платежів. Використання інших систем убезпечення платежів також є припустимим. Першим варіантом застосування є ініціалізація криптокарти у зоні системи убезпечення платежів. Для ініціалізації криптокарти мають бути виконані дії, більшість яких можуть бути здійснені з використанням інструмента менеджменту WebSentryManager: 21 - Встановлення і конфігурування карти, завантаження вбудованих програм, якщо цього не зробив виробник. Вбудовані програми містять Embedded Code (вбудований код власних програм). Ця функція вбудована у WebSentryManager. - Визначення кластерів (з декількома криптокартами) (WebSentryManager). - Імпортування ГТК, див. окремий варіант застосування (функції виконує WebSentryManager). - Користувацька адміністрація: стирання адміністратора безпеки за замовчування і визначення адміністратора безпеки з включенням правил аутенти фікації реквізитів (на основі смарткарти). - Генерування двох "нормальних" користувачів (один для верифікації ключа, один для імпортування ключа), які авторизують себе через заздалегідь визначений PIN. Тут функції також виконує WebSentryManager. - Імпортування CK (див. див. окремий варіант застосування). - Імпортування TК (див. див. окремий варіант застосування). - Як варіант, імпортування ключів даних (див. варіант їх застосування). Ключі мають імпортуватись у наведеній вище послідовності. Карту можна ініціювати у центральному місці, причому має бути ініціалізований комп'ютер повної криптосистеми, оскільки карта WebSentry стирає внутрішню пам'ять, як тільки карту виймають з щілини PCI. Бажано, щоб ГТК міг бути імпортований лише щонайменше двома адміністраторами безпеки, які локально ідентифікують себе для криптосистеми за допомогою зчитувача з смарт-карт і відповідної смарт-карти. Важливість ГТК вимагає, щоб цей ключ міг бути імпортований у картку лише під подвійним контролем. Це означає, що у варіанті застосування "головний транспортний ключ" потрібно мати щонайменше дві захищені персональним кодом PIN смарт-карти. Оскільки ГТК може бути завантажений у карту лише з використанням обох смарт-карт, а використання ключа захищене PIN, це гарантує, що цей ключ може бути встановлений у карті лише під подвійним контролем. Цим забезпечується дуже високий рівень захисту від доступ у до ключа. Ця функція забезпечується інструментом WebSentryManager, який дозволяє завантажувати так званий локальний головний ключ (ЛГК відповідає ГТК у цьому варіанті) з використанням смарт-карти і зберігати їх у захи щеній зоні карт. Особливо зручно розподіляти ЛГК між трьома смарт-картами, причому для імпортування ЛГК у криптообладнання необхідно мати всі три смарткарти, а в імпортуванні ГТК мають брати участь три адміністратори безпеки. Сигнатурний ключ забезпечує цілісність ключових повідомлень; його можна також використовувати перед імпортуванням ключа для перевірки, чи є передавачем центр передачі вартостей (Поштовий Пункт). Генерування CK можна здійснювати різними шляхами, але бажаними є ілюст 84861 22 ровані наведеними тут прикладами.. Належне ключове повідомлення зберігається адміністратором безпеки на дискеті і, у даному варіанті, імпортується у криптокарту системи убезпечення платежів, яка підлягає ініціалізації. Для імпортування ключа ключове повідомленні дешифрується за допомогою ГТК (функція C_Unwrap PKCS 11, механізм CKM_KEY_WR AP_WEBSENTR Y). Ця програма автоматично перевіряє цілісність цього повідомлення. Якщо ключ з таким KеуID вже існує, його стирають. Для подальшого транспортування транспортних ключових повідомлень сервер системи убезпечення платежів надає інтерфейс, через який можуть бути ініційовані розподілення і подальше імпортування у криптосистеми індивідуальних систем убезпечення платежів. Інтерфейс реалізують як сервіс RMI, який викликають засобами сервісу найменувань (JNDI). Розподілення виконується через CWMS (комп'ютеризована робоча система менеджменту), яка розподіляє список P/N. Якщо створено нову функцію розподілення, ключове повідомлення пересилається до всіх поточно зареєстрованих криптосистем з складанням протоколу у кожному випадку Розпорядження криптосистемами здійснюється з застосуванням системи убезпечення платежів. Прийом нових ключових повідомлень в індивідуальних криптосистемах перевіряється засобом ImportController з регулярним інтервалом (як функція механізму розподілення). Після прийому нового повідомлення автоматично ініціюється функція застосування "імпортування ТК" Значення, яке повертає ця процедура, перевіряється. У випадку негативного зворотного зв'язку спроба імпортування повторюється до трьох разів. Якщо після трьох спроб імпортування не проходить, до центральної системи ZinS надсилається протокольне повідомлення про неуспіх (як функція механізму транспортування). У випадку успішного імпортування надсилається позитивне протокольне повідомлення. Протокольні повідомлення обробляються функцією "обробка ключа протоколу". Відповідним чином ініціюється вивільнення TK. Імпортування TК виконується адміністратором безпеки, який інціалізує криптосистему на місці, або це імпортування ініціюється автоматично функцією ImportController розподілення ключів, коли ImportController отримує нове транспортне ключове повідомлення. Бажана процедура імпортування ключа включає такі операції: 1. Реєстрація у карті через ID і PIN користувача Keylmport. 2. Для полів 1-5 транспортного ключового повідомлення формується хеш-значення методом SHA-1. 3. Підтверджується CK, який відповідає KeylD поля 4. 4. Цей ключ використовується для шифрування хеш-значення, сформованого у п.2 (механізм CKM_DES3_CBC_PAD, вектор IV ініціалізації заповнюється нулями), яке порівнюється з полем 23 6. Якщо значення збігаються, цілісність підтверджується, і це означає, повідомлення було створене франкувальною системою PC. 5. Вміст поля 5 повідомлення дешифрується ключем ГТК (метод C_UnwrapKey, механізм CKM_KEY_WR AP_WEBSENTR Y). B результаті належний об'єкт TК генерується автоматично і зберігається у карті. Крім того, цей механізм знову неявно перевіряє цілісність ключа і джерело. 6. Якщо ключ з таким же KeylD вже існує, він стирається. 7. Для атрибута L ABEL щойно імпортованого ключа методом SHA-1 формується хешзначення, яке потім повертається разом з KеуID і позитивним повідомленням як повернуте значення. 8. Кінець користувацького сеансу. 9. З повернутих значень формується протокольне повідомлення, яке надсилається до центральної системи ZinS. 10. Будь-яка неуспішна спроба, збережена для цього KеуID, повторюється (див. варіант, описаний нижче). У випадку, коли не спрацьовує одна програм або перевірка МАС, подальша обробка припиняється і повертається значення, яке містить KеуID, код помилки і повідомлення про помилку. Щодо KеуID, збережена кількість невдалих спроб підвищується на 1. Коли ця кількість досягає 3, на основі останнього переданого повернутого значення формується протокольне повідомлення і надсилається до центральної системи убезпечення платежів. У випадку ручного ініціювання результат імпортування виводиться на монітор адміністратора безпеки. Бажано, щоб операції 2-7 виконувались програмами (вбудованим кодом) карти. Це підвищує ефективність і захист від проникнення. Для подальшого транспортування повідомлень ключа даних сервер центральної системи убезпечення платежів надає ще один інтерфейс, через який здійснюється розподілення і подальшеімпортування ключів даних в індивідуальні криптосистеми локальних систем убезпечення платежів. Інтерфейс реалізовано як Sessio Bean; це обслуговування викликають з використанням сервісу найменувань (Java Naming and Directory Interface - JNDI). Розподілення виконується через CWMS (комп'ютеризована робоча система менеджменту), яка розподіляє список P/N. При створенні нової функції розподілення ключове повідомлення пересилається до всіх поточно зареєстрованих криптосистем з складанням протоколу у кожному випадку. Розпорядження криптосистемами здійснюється з застосуванням системи убезпечення платежів. Якщо ключ даних вже є у обігу, для якого від центра передачі вартостей (Поштового Пункту), розподілення нових ключів даних блокується до отримання зворотного зв'язку. Прийом нових ключових повідомлень перевіряються в індивідуальних криптосистемах за до 84861 24 помогою ImportController з регулярним інтервалом (як функція механізму розподілення) Після прийому нового повідомлення автоматично ініціюється функція застосування "імпортування ТК". Значення, яке повертає ця процедура, перевіряється. У випадку негативного зворотного зв'язку спроба імпортування повторюється до трьох разів. Якщо після трьох спроб імпортування не проходить, до центральної системи ZinS надсилається протокольне повідомлення про неуспіх (як функція механізму транспортування). У випадку успішного імпортування надсилається позитивне протокольне повідомлення. Протокольні повідомлення обробляються функцією "обробка ключа протоколу". Відповідним чином ініціюється вивільнення TК. Імпортування TК виконується адміністратором безпеки, який інціалізує криптосистему на місці, або це імпортування ініціюється автоматично функцією ImportController розподілення ключів, коли ImportController отримує нове повідомлення ключа даних. Бажана процедура імпортування ключа включає такі операції: 1. Реєстрація у карті через ID і PIN користувача Keylmport. 2. Для полів 1-7 транспортного ключового повідомлення формується хеш-значення методом SHA-1. 3. Підтверджується CK, який відповідає KеуID поля 5. 4. Цей ключ використовується для шифрування хеш-значення, сформованого у п.2 (механізм CKM_DES3_CBC_PAD, вектор IV ініціалізації заповнюється нулями), яке порівнюється з полем 8. Якщо значення збігаються, цілісність підтверджується, і це означає, повідомлення було створене франкувальною системою PC. 5. Визначається TК, якому належить KеуID, визначений у полі 6. 6. Вміст поля 7 повідомлення дешифрується ключем, визначеним у п.5 (метод C_Decrypt, механізм CKM_DES3_CBC_PAD, вектор IV ініціалізації заповнюється нулями), яке порівнюється з полем 8. Результатом дешифрування є проміжне повідомлення. 7. Вміст поля 1 проміжного повідомлення дешифр ується ключем ГТК (метод C_UnwrapKey, механізм CKM_KEY_WR AP_WEBSENTRY). B результаті належний об'єкт TК генерується автоматично і зберігається у карті. Крім того, цей механізм знову неявно перевіряє цілісність ключа і джерело. 8. Якщо ключ з таким же KеуID вже існує, він стирається. 9. Всі ключі даних у криптокарті зчитуються і перевіряються на ідентичність значення лічильника генерувань в атрибуті LABEL (байт 1) цьому значенню щойно прийнятого ключа. Якщо так, ці ключі видаляються з карти. Ці ключі є тими, що не були вивільнені у центрі передачі вартостей (Поштовому П ункті) внаслідок помилок імпортування у криптосистеми іншої локальної системи убезпечення платежів. 25 10. Для байтів 2-65 атрибута LABEL щойно імпортованого ключа формується хеш-значення (з використанням SHA-1) і повертається разом з KеуID і позитивним повідомленням. 11. Кінець користувацького сеансу. 12. З повернутих значень формується протокольне повідомлення, яке надсилається до центральної системи ZinS. 10. Будь-яка неуспішна спроба, збережена для цього KеуID, повторюється (див. варіант, описаний нижче). У випадку, коли не спрацьовує одна програм або перевірка МАС, подальша обробка припиняється і повертається значення, яке містить KеуID, код помилки і повідомлення про помилку. Щодо KеуID, збережена кількість невдалих спроб підвищується на 1. Коли ця кількість досягає 3, на основі останнього переданого повернутого значення формується протокольне повідомлення і надсилається до центральної системи убезпечення платежів (центральної ZinS). У випадку ручного ініціювання результат імпортування виводиться на монітор адміністратора безпеки. Бажано, щоб операції 2-10 виконувались програмами (вбудованим кодом) карти. Це підвищує ефективність і захист від несанкціонованого доступу (особливо доступу до вектора IV ініціалізації і ГТК). Очищення ключів даних виконується, бажано, регулярно, у якнайбільшій кількості криптосистем, бажано в усіх, з метою стирання тих ключів, що вже не є потрібними. Процедура очищення ключів даних: 1. Всі ключі даних у карті перевіряються і упорядковуються у порядку зростання їх ідентифікаторів (ID), тобто атрибута CКA_ID. 2. Для кожного ключа з цього списку виконується така процедура перевірки: I. Визначається наступний ключ (з наступним більшим ID). II. Якщо такий ключ є, відбувається перевірка того, що: 1. атрибут CКA_END_DATE наступного ключа, який вказує дату закінчення дійсності, є меншим з поточну дату, і якщо так, то ключ з списку, що у цей момент обробляється, стирається; 2. лічильник генерувань наступного ключа (байт 1 атрибута CКA_LABEL) є ідентичним лічильнику генерувань ключа, що обробляється у цей момент; якщо це так, ключ, що обробляється у цей момент, стирається. Обробку ключа бажано протоколювати у сервері центральної системи убезпечення платежів (центральному сервері ZinS). Ключі, що протоколюються у даному випадку, є TК і ключем даних. Для кожної операції розподілення сформований протокол вказує, до якої з активних криптосистем було надіслано ключове повідомлення. Для кожної системи і кожної операції розподілення формується окремий запис з початковим статусом "надіслано". Після кожної успішної і неуспішної обробки ключа індивідуальні криптосистеми генерують протокольне повідомлення і надсилають його до 84861 26 центральної системи убезпечення платежів (центральної системи ZinS). Це розподілення здійснюється з застосуванням черг JMS або з реплікацією бази даних. У зоні центральної системи убезпечення платежів після прийому повідомлень вони використовуються для оновлення зазначених вище протокольних записів. Для цього зберігається статус "успішна обробка" або код помилки і повідомлення. Після обробки протокольних повідомлень здійснюється перевірка, чи існують операції розподілення, успішно введені всіма криптосистемами. Якщо так, ініціюється вивільнення кожного відповідного ключа, зокрема, у зоні центра передачі вартостей (Поштового Пункту). Як тільки система сповіщає про помилку, у зоні центра передачі вартостей (Поштового Пункту) формується відповідне повідомлення з негативним статусом. Той факт, що було ініційоване вивільнення ключа відзначається у примітці разом з операцією розподілення і тому для даної операції додаткове вивільнення не здійснюється. Але доки ця примітка не введена, повторюються (з регулярним інтервалом) спроби контакту з службою вивільнення. Особлива ситуація створюється, коли після визначеного періоду часу, бажано, через декілька днів, наприклад, три дні, не отримується зворотний зв'язок від усіх криптосистем. У цьому випадку до центра передачі вартостей (Поштового Пункту) надсилається негативне повідомлення про вивільнення. Бажано, щоб система призначення ключів мала користувальний інтерфейс, який дозволяє адміністратору перевіряти статус операції розподілення ключа. Для кожної операції розподілення на індикацію виводяться такі дані: - кількість систем до яких було надіслане повідомлення про розподілення, - кількість систем, які доповіли про успішну обробку, - кількість систем, які ще не доповіли про результат обробки, - кількість систем, які доповіли про неуспішну обробку. Крім того, може бути складений перелік поточних ста тусів всі х ци х систем. В іншому варіанті можна локально виводити на індикацію ключі, введені у належні карти. Доцільно архівува ти у зоні центральної системи убезпечення платежів всі ключі, для яких були ініційовані операції розподілення. Бажано не проводити архівування у локальних системах. У них ключі зберігаються у енергонезалежній пам'яті карти. Архівуються лише ті ключові повідомлення, які були також вивільнені. Відновлення ключів TК і ключів даних можна ініціювати централізовано для конкретної криптосистеми. У цьому випадку поточні ключі виявляються в архіві і надсилаються до цієї криптосистеми. Для цього формуються також протокольні повідомлення. У такому варіанті розподілення 27 ключів відсутнім є лише повідомлення про вивільнення. У випадку втрати ГТК відповідну криптосистему надсилають до адміністраторів безпеки для нової ініціалізації або адміністратори безпеки мають ініціалізувати кожну систему на місці. ГТК надійно захищений проти втручання спеціальними заходами безпеки карти Web-Sentry і розподіленням у декількох смарт-картах, а також багатостадійною системою ключів. Якщо має бути проведена заміна ГТК, необхідно генерувати новий ГТК, транспортні ключі і ключі даних. Після цього вони мають бути імпортовані в усі криптосистеми локальних систем убезпечення платежів. Це потребує більше операцій, оскільки необхідно або транспортувати всі криптосистеми до місця центральної адміністрації і назад, або адміністратори безпеки мають відвідати всі місця локальних систем убезпечення платежів. Тому використання механізму захисту для ГТК згідно з винаходом є особливо зручним. Попередній ГТК запишається у карті як так званий "бездіяльний ГТК" і має бути стертий адміністратором безпеки. Робота з ключем і дешифрування запрограмовані у криптокарті вбудованим кодом. Цим досягається не лише кращий захист, але й підвищення ефективності криптосистеми. Бажано, щоб криптокарти містили такі стандартні функції PKCS 11: C_CloseSession C_GetSlotList C_Init С_Initialize C_Login C_Logout C_OpenSession разом з розширеннями. Крім того, функції, що зберігаються постійно, не повинні мати будь-яких подальших розширень третіми особами, а необхідні розширення ексклюзивно інтегруються як функції для криптокарт системи убезпечення платежів. Для позначення вбудованих операцій DLL PKCS 11 їм надано префікс СЕ_ (Crypto Extension). Кожний вбудований метод повертає значення типу CK_RV, який визначається як фіксований include-файл pkcs11.h. Зручним є те, що під час використання вбудованих функцій повертаються додаткові коди помилок і вносяться у файл заголовка C++ для інтегрування. Це надає ту перевагу, що викликом вбудованої функції викликаються різні методи Pkcs11, включені у схему. Іншою перевагою є застосування нового порядку роботи с ключами, визначеного програмами криптокарт. Приклад синтаксису цього способу: CK_RV= CE_MethodName (список параметрів) У цьому списку параметрів параметри, що мають бути заповнені результатом, передаються через виклик посиланням. Ім'я методу формується з комбінацій значущи х слів, які дають уявлення про метод. 84861 28 Вибір слів здійснюється таким чином, щоб створити асоціацію з вмістом, наприклад, використовуючи англійську те хнічну термінологію. Введення двох типів нумерації слугує для верифікації функцій різних вбудованих методів. Типи нумерації типів ключів і атрибутів ключів є різними. CE_EnumKey= {CE_KT, CE_DT, CE_SE, CE_KA} СЕ_KА займає особливу позицію. Це не ключ, а, скоріше, набір всіх ключів. Якщо вказаний цей KeyElement, то метод виконує функцію, що стосується всіх ключів у карті. CE_EnumKeyAttribute= (CF_ID, CE_LABEL, CE_STARTDATE, CE_ENDDATE} Необхідні значення необхідно внести у файл pkcs.h. Визначені розширення можна розмістити в окремому заголовку, включеному у pkcs.h. Для реалізації вбудованих методів можуть бути використані різні механізми. У криптографічному середовищі визначається метод, який виконує всі необхідні верифікації наявними методами PKCS 11. CK_RV_CE_Decrypt (сеанс CK_SESSION_HANDLE) повідомлення CK_BYTE [], поштовий ідентифікатор CK-BYTE* CK_BBOOL bOk Опис функції: Вбудований криптографічний метод приймає 57-байтову дату у параметричному повідомленні, яка відповідає матричному коду поштового штемпелю. У наведеному далі описі відлік починається з одиниці. Операція 1: формування вектора IV ініціалізації, в якому перші два байти заповнюються нулями, а байти f6-f10, f14 додаються до матричного коду. Операція 2: визначення ключа даних, що має використовува тись. Індикатор фази ключа міститься у байті f14 і вказує, який ключ має бути використаний. Цей індикатор міститься в атрибуті CКA_ID ключа і однозначно ідентифікує ключ. Обробка ключа, описана далі, має забезпечувати ефективний пошук ключа. Операція 3: дешифрування включеного шифрованого повідомлення. У CK_MECHANISM використовується механізм CKM_DES3_CBC. Дешифруються 24 байти f15-f38 і перші 12 байтів дешифрованого результату виводяться поштовим ідентифікатором параметра. Після успішного дешифрування виконується операція 4, в іншому разі - операція 5. Операція 4: формування і очищення хешзначення. Спеціальний 77-байтовий блок даних слугує основою формування хеш-значення дати. Байти 1-53 відповідають першим 53 байтам матричного коду. Байти 54-65 відповідають першим 12 байтам поточної нешифрованої частини повідомлення (поштовий ідентифікатор). Байти 66-77 відповідають останнім 12 байтам поточної нешифрованої частини повідомлення. 29 84861 Хеш-значення формується за допомогою SHA-1 і після цієї процедури перші 4 байти мають збігатись з байтами f54-f57. Якщо вони не збігаються, це означає, що дата не є дійсною. Якщо під час хешування виникає помилка або є незгідність у хеш-значенні, виконується операція 5. Операція 5: повертання індикатора успіху. Параметру bOk надається значення TRUE, якщо всі попередні операції були успішними, і значення FALSE, якщо при очищенні хеш 30 значення були виявлені незгідності або якщо один з методів Pkcs 11 спричинив помилку. Повернуте значення має містити відповідне повідомлення про помилку або мати значення CKR_OK у випадку відсутності помилок. CK_RV DE_VerifyMsg (сеанс CK_SESSION_HANDLE) CK_BYTE {} - int length CK_BBOOL bOk Загальний блок даних має вигляд: Блок даних для процедури верифікації П.п. Дов- №№ жина байт 1 2 f1-f2 2 3 4 5 6 7 8 9 Призначення Опис MsgTYpe Ідентифікатор ключового повідомлення, константа "КT" або "КД" Версія структури повідомлення, 1 байт, що починається з значення 1 F3 Version "01" 2 f4-f5 KeyGeneration Лічильник генерувань прямим текстом, наприклад, "01" 4 f6 KeylD Ідентифікатор ключа даних прямим текстом 4 f7-f11 KeylD Ідентифікатор TК прямим текстом 4 f12-f16 SigKeylD Ідентифікатор ключа, що використовується для сигнатури Ідентифікатор TК, що використовується для шифрування проміжного 4 f17-f21 KTID повідомлення (див. п.2) TranspKeyEncrypt Результат ши фрування (згортання) TК. п-22 f22-fn HelperMsgEncrypt Ключ даних: результат ши фрування проміжного повідомлення TK: МАС для ключового повідомлення; формується як хеш-значення SHA-1 для полів 1+2+5+6+8 повідомлення, причому це значення шифр ується сигнатурним ключем (механізм CKM_DES3_CBC_PAD, IV заповнюється нулями, ID -див. п.6). 24 fn+1-f n+24 MAC Ключ даних: МАС для ключового повідомлення; формується як хешзначення SHA-1 для полів 1+2+4+3+6+7+8 повідомлення, причому це значення шифрується сигнатурним ключем (механізм CKM_DES3_CBC_PAD, IV заповнюється нулями, ID - див. п.6). Невикористані поля заповнюються нулями. Режим виконання метода визначається параметром MsgType. Генерований блок даних передається у повідомленні для MsgType TК і ключа даних. Блок даних заповнюється з кожним прийнятим повідомленням. Функція призначення CE_VerifyMsg для MsgType TК приймає повне транспортне ключове повідомлення в атрибуті MESSAGE, а його довжину у вер хній частині шахти ліфта атрибуті LENGTH. Це вбудоване повідомлення слугує для забезпечення цілісності транспортного ключового повідомлення у реципієнта. Для активування верифікації виконуються такі операції: Операція 1: формування вектора IV ініціалізації, який заповнюється нулями. Операція 2: дешифрування прийнятого шифрованого повідомлення. У CK_MECHANISM використовується механізм CKM_DES3_CBC. Дешифр уються змінні поля МАС. При наявності помилок виконується операція 4. Операція 3: очищення хеш-значення. Хеш-значення дати формується з полів 1+2+5+6+8 транспортного ключового повідомлення і порівнюється з хешем операції 2. Хешзначення формується з використанням SHA-1. Якщо хеш-значення є не ідентичними, то дата не є дійсною. Якщо під час хешування виявляється помилка або якщо виявлено незгідності у хешзначенні, виконується операція 4. Операція 4: повертання індикатора успіху. Параметру bОk надається значення TRUE, якщо всі попередні операції були успішними, і значення FALSE, якщо при очищенні хешзначення були виявлені незгідності або якщо один з методів Pkcs 11 спричинив помилку. Повернуте значення має містити відповідне повідомлення про помилку або мати значення CKR_OK у випадку відсутності помилок. Після виконання функції призначення CE_VerifyMsg для MsgType ключа даних повне повідомлення ключа даних передається в атрибуті MESSAGE, а його довжина в атрибуті LENGTH. Це вбудоване повідомлення слугує для забезпечення цілісності транспортного ключового повідомлення у реципієнта. Для активування верифікації виконуються такі операції: Операція 1: формування вектора IV ініціалізації, який заповнюється нулями. Операція 2: дешифрування прийнятого шифрованого повідомлення. У CK_MECHANISM використовується механізм CKM_DES3_CBC. Дешифр уються змінні поля МАС. При наявності помилок виконується операція 4. Операція 3: очищення хеш-значення. Хеш-значення дати формується з полів 1+2+4+3+6+7+8 повідомлення ключа даних і порівнюється з хешем операції 2. Хеш-значення формується з використанням SHA-1. Якщо хе шзначення є не ідентичними, то дата не є дійсною. Якщо під час хешування виявляється помилка 31 або якщо виявлено незгідності у хе ш-значенні, виконується операція 4. Операція 4: повертання індикатора успіху. Параметру bОk надається значення TRUE, якщо всі попередні операції були успішними, і значення FALSE, якщо при очищенні хешзначення були виявлені незгідності або якщо один з методів Pkcs 11 спричинив помилку. Повернуте значення має містити відповідне повідомлення про помилку або мати значення CKR_OK у випадку відсутності помилок. Ці вбудовані методи обробки ключа мають включати імпортування згорнутого ключа і ефективний менеджмент. Мають бути імпортовані ключі типу CК, ключ даних, TК. CK_RV CE_ImportKey (сеанс CK_SESSION_HANDLE, довжина CKJJLONG, CK_BYTE* HashValue CE_EnumKey KeyType CK_CHAR [] KeyKTID) Функцію призначення CE_ImportKey бажано виконувати, як це описано нижче. Для згортання і розгортання використовується механізм CKM_KEY_WR AP_WEBSENTRY. Отриманий ключ імпортується у криптообладнання розгортанням, причому ключ, який імпортується вдруге, тобто з тією ж фазою ключа, записується замість старого ключа. Згорнутий ключ вноситься у параметр DATA, а його довжина у параметр LENGTH. Довжина ключа залежить від заповнення атрибутів ключа. Тип ключа верифікується параметром Key Type і обробляється відповідним чином. Далі ключ вноситься у менеджмент ключа, що входить у кеш-операцію і дублікатпопередник, якщо він є, стирається. Ключ даних де шифр ується транспортним ключем TК, ідентифікованим параметром KeyKTID; для всіх інших типів ключа цей параметр не розглядається і заповнюється нулями. Залежність від атрибута CKA_END_DATE є важливою. Він визначає кінцеву дату попередника ключа. Атрибут імпортованого ключа містить рандомізоване число, через яке за допомогою SHA-1 формується хеш-значення. Це значення повертається у параметрі HashValue вбудованого метода і є необхідним для повідомлення підтвердження ключа. У випадку появи помилки при застосуванні механізму розгортання повертається код помилки, в іншому випадку повертається CKR_OK. CK_RV CE_GetKeyCount (сеанс CK_SESSION_HANDLE, CE_EnumKey Key Type, int* counter) Функція призначення CE_GetKeyCount вказує, скільки ключів кожного типу зареєстровано у карті у менеджмент ключа, що входить у кешоперацію. Завдяки цьому атрибути ключа можуть бути зчитані у сполученні з описаним нижче методом. Цей метод визначається послідовністю: CK_RV CE_GetAttribute (сеанс CK_SESSION_HANDLE, 84861 32 CE_EnumKey KeyType, CE_EnumKeyAttribute KeyAttribute, int pos, CK_BYTE [] * attribute, int* length) Тип ключа визначається параметром KеуТуре, і, отже, також таблицею, яку зчитують під час запису різних типів ключів у криптообладнання різними списками згідно з типом ключа. Параметр KeyAttribute визначає атрибут, який має бути зчитаний, а параметр ITEM вказує початковий пункт у таблиці; спочатку з застосуванням метода CE_GetKeyCount для всіх ключів або для одного типу ключа має бути отримане його максимальне значення. При виведенні атрибута CКA_END_DATE слід брати до уваги, що останній поточний ключ є теоретично нескінченно дійсним (до імпортування нового ключа того ж типу) і в атрибуті CКA_END_DATE містить кінцеву дату для попереднього ключа того ж типу, причому CКA_END_DATE вказує що вказаний ключ виведено. Атрибут для дати має фіксовану довжину 8 байт, а атрибути CSK_ID і CKA_LABEL мають фіксовану довжину 128 байт. Якщо ці атрибути ключа для цих двох параметрів мають бути коротшими за 128 байт, решта байт заповнюється нулями. Отже, користувач завжди має достатньо пам'яті для реалізації цих методів. Якщо буфер користувача є занадто коротким, інформацію скорочують і повідомлення передається через CK_RV. CK_RV CE_DeleteExpiredKey (сеанс CK_SESSION_HANDLE, CE_EnumKey KeyType, int* counter) Функція призначення CE_DeleteExpiredKes шукає карту для ключів з вичерпаним терміном дійсності і стирає їх. Ці ключі можна ідентифікувати тим, що їх системна дата є старішою за CKA_END_DATE наступного ключа (див.2.5.8); це також стосується TК і CК. Можна проводити селективне стирання, використовуючи EnumType, а стерти карту повністю можна засобами СK_KА (залишається лише ЛТК). Важливим є те, що цей спосіб не можна активува ти під час імпортування ключа. Це бажано контролювати у вбудованому коді і вказувати у відповідному поверненому значенні. Завдяки цьому відвертаються будь-які побічні явища у менеджменті внутрішнього ключа. Інтерфейс між системою убезпечення платежів і центром передачі вартостей (Поштовим Пунктом) бажано мати якомога вузьким, щоб виключити можливість маніпулювання через бічні канали. Структура інтерфейсу між центром передачі вартостей (Поштовим Пунктом) і центральною системою убезпечення платежів ілюструється Фіг.3. Центральна система убезпечення платежів надає інтерфейс для розподілення ключів, завдяки чому ключі, генеровані у компоненті KeyManagement центра передачі вартостей (Поштового П ункту), можуть розподілятись до криптосистем систем убезпечення платежів. 33 Центр передачі вартостей (Поштовий Пункт) надає системі убезпечення платежів інтерфейс вивільнення ключів, завдяки чому система убезпечення платежів може вивільняти ключ після його успішних розподілення і обробки. Оскільки в обох проектах використовується, в основному, Java, рекомендовано реалізувати прикладний інтерфейс через Session Beans. Обслуговування для роз'єднання цих двох систем слід викликати засобами сервісу найменувань (JNDI). Session Beans надає необхідну функціональність для імпортування даних ключа у центральну систему ZinS. Всі зв'язки показані у Фіг.4. Фіг.4 ілюструє операції процесу інтегрування ключа даних у центральну систему убезпечення платежів (центральна ZinS). Програма ImportKey переносить набір ключа даних у центральну ZinS. Залежно від використання повідомлень ASN. 1 ця програма обробляє прийняте повідомлення і викликає зберігання цього повідомлення у базі даних. Потім програма ImportKey ініціює розподілення даних ключа до локальних систем ZinS засобами CWMS. Слід дотримуватись послідовності імпортування даних у базу даних і подальшого розподілення повідомлень. Цим гарантується, що дані будуть захищені ще до закінчення роботи з ними. Перевагою цього рішення є те, що воно полегшує відновлення інформації, яка постраждала від помилок, а у випадку втрати даних за необхідності забезпечується доступ до бази даних. Параметри метода InsertKeyData ще не визначені, оскільки невідомо, чи підтримується формат ASN.1. Однак, цей метод може бути поповнений двома параметрами, які уможливлюють надсилання деталізованого повідомлення до Поштового Пункту. У центральній ZinS цей спосіб розподілення забезпечує виконання таких функцій: 1. Ар хівування ключового повідомлення у центральному сервері ZmS 2. Розподілення ключових повідомлень від Поштового Пункту до індивідуальних поштови х центрів через інтерфейс CWMS, наданий Vibris; структур у ι використання сервісу CWMS описано в інструкціях до цього інтерфейсу. 3. Після завершення розподілення і імпортування в індивідуальні поштові центри генерується відповідне зворотне повідомлення. Дані від центра передачі вартостей (Поштового Пункту) передаються у форматі ASN.1. Відповідне зворотне повідомлення також має бути у форматі ASN.1. Припустимими є також ι інші формати. Адаптування до конкретного формату здійснюється належним синтаксичним аналізатором. Бажаними форматами даних AN.1 є такі: Розподілювальне повідомлення для TК TransportKeyMessage ::= SEQUENCE { MsgType OCTET STRING, (fi x 'KT') Version OCTET STRING, (0´01) KeylD OCTET STRING, (CKA_ID) 84861 34 SigKeylD OCTET STRING, (CKA_ID SignaturKey для MAC) TransKeyEncrypt OCTET STRING, (TransportKey згортається ключем ЛТК) MAC OCTET STRING (MAC для всіх попередніх елементів) } Розподілювальне повідомлення для TК PostageKeyMessage::= SEQUENCE { MsgType OCTET STRING, (fi x 'KD') Version OCTET STRING, (0´01) KeylD OCTET STRING, (CKA_ID) KeyGeneration OCTET STRING (0´01, зростання) SigKeylD OCTET STRING, (CKA_ID SignaturKey для MAC) TransKeylD OCTET STRING, (CKA_ID TransportKey) DataKeyEncrypted OCTET STRING, (PostageKey згортається ключем ЛГК і шифрується TransportKey) МАС OCTET STRING (MAC для всіх попередніх елементів) } (див. також 2.4.6) Повідомлення вивільнення KeyExchangeReceipt::= SEQUENCE { KeylD OCTET STRING, (CKA_ID прийнятого ключа) KeyLabelHash OCTET STRING, (хеш SHA-1 для CKA_LABEL прийнятого ключа) State BOOLEAN, (TRUE/FALSE активує/деактивує ключ) Message OCTET STRING (Опис успіху/не успіху) } Можна встановити різні структури даних. Однак, структури, встановлені згідно з розглянутими втіленнями винаходу дають певні переваги, оскільки дозволяють скоротити передачу всієї суттєвої інформації. Зокрема, дані передаються через CWMS до локальних систем убезпечення платежів, які бажано розташовувати у поштови х центрах провайдера поштових послуг. При використанні формату ASN.1 дані спочатку компонують у внутрішнє ключове повідомлення, яке потім розподіляється, якщо повідомлення, визначені у цьому документі, були використані безпосередньо. Пакети даних, прийняті через CWMS, відповідають ключовим повідомленням, визначеним раніше у цьому документі. Ці повідомлення потім піддають верифікації згідно з методом VerifyMsg вбудованого коду після адаптування до наведеної вище таблиці даних "Атрибути ключа даних". Після верифікації починається або імпортування ключа згідно з вбудованим кодом або генерування повідомлення про помилку (див. ключові повідомлення і стор.6-8 з порівнянням їх між собою для з'ясування структури даних, імпортованих методом CE_ImportKey). Стирання старих ключів і оновлення виконуються автоматично згідно з описаними вище методами вбудованого коду. 35 Щоденно виконується метод CE_DeleteExpiredKeys для видалення з криптообладнання, якщо це необхідно, ключів з вичерпаним терміном дійсності. Під час імпортування цей метод гарантує стирання дублікатів ключів і їх заміну новими. Методи вбудо ваного коду реалізуються з використанням криптоадаптерів (СrурtoAdapters) класу Java, які надають всі функції (з тими ж найменуваннями), які надають вбудований код і інші методи PKCS 11. За допомогою JNI використовується DLL (CryptoAdapter.DLL), який статично зв'язує DLL, надані від Zaxus. Таке статичне зв'язування додатково підвищує безпеку. Застосування C++ для інтерфейсу JNI також забезпечує обробку помилок у кожному затребуваному сеансі (див. Стадію 3 "multithreading" у проектній документації PCFM. Робоча концепція підтримується тим, що криптообладнання ініціалізується у багатопотоковому режимі і після реєстрації у системі кожний учасник отримує власний сеанс (getSession, C_GetSession), завдяки чому учасник реєструється у DLL і обробка помилок встановлюється спеціально для нього. При реєстрації у системі спрямовується головний потік DLL і власна обробка помилок для виконання методів Pkcsi 11 і вбудованих методів. Фіг.6 ілюструє огляд застосування. Бажано, щоб список ключів і код, що забезпечується вбудованими методами, видалялись. В іншому разі мають бути встановлені ідентичні структури. Зв'язок DLL Фіг 7 містить приклади бажаної інкапсуляції і зручної обробки помилок. Застосування списків ключів є зайвим, якщо ці списки повністю лежать у вбудованому коді криптообладнання. Методи GetAttribute зводяться до простого ініціювання вбудованого метода CE_GetAttribute; відповідно, ініціювання імпортування і його застосування спрощуються, оскільки виконуються автоматично вбудованим кодом після перенесення необхідних даних. Вбудований код містить розширений постійний список помилок. Ключові повідомлення від Поштового Пункту зберігаються у базі даних центральної ZinS, щоб дозволити майбутню заміну дефектних локальних систем убезпечення платежів. Перш за все необхідно ввести повідомлення у базу даних і, по-друге, прийняти адміністративну інформацію. Отже, у базі даних потрібно мати такі таблиці: 84861 36 SDItemNo Запис даних ключа TransportKeyData INT Див табл. на стор.14 Запис даних ключа містить ключове повідомлення у тому вигляді, в якому воно було прийняте Поштовим Пунктом; у випадку відмови локальної системи убезпечення платежів архівування ключового повідомлення дозволяє координувати дефектну локальну систему убезпечення платежів з іншими локальними системами убезпечення платежів шляхом імпортування архівованого ключа. Перед зберіганням повідомлення форматується згідно з ASN.1 для того, щоб передавати його до локальних систем. Як модальність зберігання бажаною є спільна форма записів даних; це відповідає таблиці, яка описує блок даних, використаний у вбудованому методі CE_VerifyMessage. TransportKeyManagement SNItem Number ReceiptDate DATE (/ timestamp) CompletionDate DATE (/ timestamp) DistributioDate DATE (/ timestamp) EndStatus VARCHAR (20 StatusText VARCHAR (20) Цей запис даних має центральне значення. По-перше, від слугує для оцінювання зворотного зв'язку, прийнятого від локальної системи убезпечення платежів у пошто вих центрах, бажано, в усі х поштових центрах, інтегрованих у поштову систему провайдера поштових послуг, а також для проведення належного аналізу помилок і для формування тривожного сигналу для оператора системи у випадку перевершення часу під час процедури розподілення. Відповідно, ця таблиця пов'язана з обробкою адміністративної інформації. Це уможливлює використання поля SNItemNo для призначення і оцінювання відповідної таблиці Trans-portKeyData і TransportKeyReplayMessage індивідуальних (83) поштових центрів, якщо це необхідно. TransportKeyReplayMessage SNItem Number MailCenterNo Number MessageDate DATE (/ timestamp) MessageText VARCHAR (520) У цій таблиці індивідуальні ключові повідомлення-відповіді локальних систем убезпечення платежів архівуються у поштови х центрах провайдера поштових послуг як функція процедур імпортування. 37 84861 38 39 84861 40 41 84861 42 43 84861 44 45 84861 46 47 84861 48 49 Комп’ютерна в ерстка Т. Чепелев а 84861 Підписне 50 Тираж 28 прим. Міністерство осв іт и і науки України Держав ний департамент інтелектуальної в ласності, вул. Урицького, 45, м. Київ , МСП, 03680, Україна ДП “Український інститут промислов ої в ласності”, вул. Глазунова, 1, м. Київ – 42, 01601