Міністерство освіти і науки України
Чернівецький національний університет імені Юрія Федьковича
Факультет комп’ютерних наук
Кафедра комп’ютерних систем та мереж
Реферат
Аутентифікація користувачів на основі токенів безпеки
2007
Правильне функціонування підсистеми безпеки комп‘ютерної системи вимагає реалізації ряду функцій загального призначення, пов‘язаних з перетворенням вмісту об‘єктів системи (файлів, записів бази даних тощо) або з обчислення деяких спеціальних функцій, які суттєво залежать від вмісту об‘єктів. До таких функцій належать алгоритми контролю цілісності об‘єктів, аутентифікації та авторизації об‘єктів, що керують процесами, а також алгоритми підтримання конфіденційності інформації, що міститься в об‘єктах комп‘ютерної системи.
Міжнародні та національні стандарти описують ряд добре відомих та вивчених функцій захисного характеру, зокрема алгоритми хешування MD5, MD2, SHA тощо; алгоритми генерування та перевірки електронного цифрового підпису RSA, DSS та інших. Усі ці алгоритми мають різні механізми викликів (зокрема, різну довжину аргументів). Це, у свою чергу, означає, що вони несумісні між собою.
Тому задача вбудовування тих чи інших захисних механізмів в операційну систему на основі якогось одного алгоритму буде виглядати неефективною, особливо, якщо ця ОС розповсюджується в різних регіонах земної кулі. В цьому випадку логічним є побудова "шаруватої" структури, де окремий шар, реалізований, скажемо, як набір динамічних бібліотек, відповідає за захист інформації. Цей спосіб досить універсальний і широко застосовується у сімействі операційних систем Windows. Таким способом можна розв‘язати великий клас задач, пов‘язаних з універсалізацією ОС: від національних налаштувань системи до реалізації різноманітних засобів безпеки.
Зрозуміло, що такі структури повинні мати т.зв. "відкритий інтерфейс", тобто бути детально документованими для того, щоби програмісти могли використати засоби цієї структури при створенні прикладного програмного забезпечення, в тому числі і для захисту інформації.
Сьогодні є достатня кількість криптографічних інтерфейсів, однак найбільшої популярності набув інтерфейс від Microsoft - Microsoft CryptoAPI. Зараз використовується CryptoAPI версії 2.0. Причина популярності цього інтерфейсу полягає в тому, що Microsoft інтенсивно впровадила захисні механізми CryptoAPI у свої операційні системи та прикладне програмне забезпечення. Сучасні ОС сімейства Windows містять багато криптографічних підсистем різного призначення як прикладного рівня, так і рівня ядра. Провідну роль в цьому грають якраз функції CryptoAPI, зокрема базові криптографічні функції, сукупність яких створює інтерфейс CryptoAPI 1.0.
Інтерфейс CryptoAPI 2.0 містить як базові криптографічні функції, так і функції, що реалізують перетворення вищого рівня – роботу з сертифікатами Х.509, обробку криптографічних повідомлень PKCS#7 та інші функції, що підтримують інфраструктуру відкритих ключів. Однак набір базових криптографічних функцій цього інтерфейсу утворює CryptoAPI 1.0. Таким чином, функції CryptoAPI 1.0 утворюють криптографічне ядро прикладного рівня для сучасних операційних систем лінійки Windows.
Загальну архітектуру CryptoAPI 1.0 подано на рис. 1.
Рис. 1. Загальна архітектура CryptoAPI 1.0.
Усі функції інтерфейсу зосереджено у бібліотеці advapi32.dll. Ці процедури виконують ряд допоміжних функції та викликають бібліотеки, де безпосередньо реалізовано відповідні криптографічні перетворення. Такі бібліотеки називають криптопровайдерами. Криптопровайдери мають стандартний набір функцій, який налічує 23 обов‘язкових та 2 необов‘язкових процедури. Ці процедури подано у таблиці 1.
Таблиця 1 Функції криптопровайдерів
| Функція | Короткий опис |
| CryptAcquireContext | Використовується для створення дескриптора ключового контейнера у рамках визначеного криптопровайдера (КП). |
| CryptContextAddRef | Збільшує на одиницю лічильник посилань на дескриптор КП. |
| CryptEnumProviders | Використовується для отримання першого та наступних доступних КП. |
| CryptEnumProviderTypes | Використовується для отримання першого та наступних доступних типів КП. |
| CryptGetDefaultProvider | Повертає КП, встановлений за замовчуванням для вказаного типу КП. |
| CryptGetProvParam | Повертає параметри КП |
| CryptReleaseContext | Вивільняє дескриптор КП |
CryptSetProvider CryptSetProviderEx |
Задає тип та назву КП за замовчуванням |
| CryptSetProvParam | Встановлює параметри КП |
| CryptDeriveKey | Створює сесійні криптографічні ключі з ключового матеріалу |
| CryptDestroyKey | Звільняє дескриптор ключа |
| CryptDuplicateKey | Робить копію криптографічного ключа |
| CryptExportKey | Експортує криптографічні ключі із заданого контейнера |
| CryptGenKey | Генерує випадкові криптографічні ключі та ключові пари |
| CryptGenRandom | Генерує випадкову послідовність та зберігає її в буфері |
| CryptGetKeyParam | Повертає параметри ключа |
| CryptImportKey | Імпортує криптографічні ключі з ключового блоба у контейнер КП |
| CryptSetKeyParam | Встановлює параметри ключа |
| CryptDecrypt | Виконує операцію розшифрування даних |
| CryptEncrypt | Виконує операцію за шифрування даних |
| CryptCreateHash | Створює хешований потік даних |
| CryptDestroyHash | Знищує об‘єкт хеш функції |
| CryptDuplicateHash | Створює точну копію хеш-об‘єкта |
| CryptGetHashParam | Повертає параметри хеш-об‘єкта |
| CryptHashData | Додає дані до хеш-об‘єкта |
| CryptHashSessionKey | Підмішує до хеш-об‘єкта сесійний ключ |
| CryptSetHashParam | Встановлює параметри хеш-об‘єкту |
| CryptSignHash | Обчислює значення ЕЦП від значення хешу |
| CryptVerifySignature | Перевіряє ЕЦП заданого значення хешу |
Як бачимо з таблиці, CryptoAPI 1.0 підтримує усі основні методи криптографічного перетворення даних: від генерування криптографічних послідовностей випадкових чисел до операцій з електронним цифровим підписом. Таким чином, знаючи інтерфейс CryptoAPI 1.0, програміст може досить легко реалізувати усі популярні криптографічні алгоритми у своїх прикладних програмах.
Одна з основних функцій пластикової картки – забезпечення ідентифікації її власника як суб’єкта платіжної системи. Для цього на пластикову картку нанесено логотипи банку-емітента та платіжної системи, яка обслуговує картку, ім’я власника картки, номер його рахунку, термін дії картки і т.ін. Крім цього, на картці може бути фотографія власника картки та його підпис. Алфавітно-цифрові дані - ім.’я, номер рахунку та ін., можуть бути ембосовані. Це дає можливість швидко перенести дані на чек за допомогою спеціального пристрою, який "прокатує" картку (аналогічно до копіювання при друкуванні на друкарській машинці)
Графічні дані забезпечують можливість візуальної ідентифікації картки. Для використання картки у платіжній системі необхідно зберігати дані на картці у форматі, який дозволяє виконувати процедуру автоматичної аутентифікації. Ця задача може бути вирішена з використанням різних фізичних механізмів.
Картки зі штрих-кодом використовують код, аналогічний тому, що використовують для маркування товарів. Як правило кодова стрічка закривається непрозорим матеріалом, і зчитування відбувається в інфрачервоних променях. Картки зі штрих-кодом досить дешеві та прості у виготовленні. Остання особливість зумовлює їх слабкий захист від підробки та робить їх мало придатними для використання у платіжних системах.
Картки з магнітною стрічкою сьогодні найбільш розповсюджені – у вжитку знаходяться понад 2 млрд. подібних карток. Магнітна стрічка розміщується на зворотній стороні картки та, згідно зі стандартом ISO 7811, складається з трьох доріжок. Перші дві призначені для зберігання ідентифікаційних даних, а на третю можна записувати інформацію (наприклад, поточне значення суми грошей на рахунку). Однак внаслідок малої надійності запису на магнітну стрічку, режим запису, як правило, не практикується, а так картки використовуються лише у режимі читання.
Як же влаштована картка? Принцип магнітного запису на карту нічим не відрізняється від звичайного звукозапису. Знищення інформації можна виконувати постійним магнітом з концентратором магнітного потоку. Запис виконують без підмагнічування, оскільки тоді досягаються більш різкі переходи намагнічування носія.
Програміст, який працює з цим інтерфейсом, може отримати усю необхідну інформацію про певного криптопровайдера засобами функції CryptGetProvParam. Перше, що необхідно знати при цьому – це набір криптографічних стандартів, які реалізують встановлені у системі крипто- провайдери.
Окрім різниці у стандартах, криптопровайдери відрізняються способом фізичної організації збереження ключової інформації. З точки зору програмування спосіб зберігання ключів значення не має, однак він дуже важливий з точки зору експлуатації та безпеки комп‘ютерної системи. Існуючі криптопровайдери Microsoft зберігають ключову інформацію на жорсткому диску (у реєстрі або у файлах), а провайдери інших фірм (GemPlus, Schlumberger та Infineon) – на смарт-картках.
Якщо способи фізичної організації збереження ключової інформації у криптопровайдерів відрізняється, то логічна структура, яка визначається інтерфейсами та з якою мають справу програмісти, однакова для будь-якого типу провайдера. Ключова база визначається набором ключових контейнерів, кожен з яких має ім‘я, що привласнюється йому при створенні, а потім використовується для роботи з ним. У ключовому контейнері зберігається довготривала ключова інформація, наприклад, ключові пари для цифрового підпису або несиметричної системи шифрування.
Тепер розглянемо детально, як функції інтерфейсу CryptoAPI викликають бібліотеки конкретного криптопровайдера. Кожен криптопровайдер має своє власне ім‘я та тип. Його ім‘я – просто рядок, за допомогою якого система його ідентифікує. Так, базовий криптопровайдер Microsoft має назву Microsoft Base Cryptographic Provider v1.0. Тип криптопровайдера – ціле число (у нотації С – DWORD), значення якого ідентифікує набір криптографічних алгоритмів, що підтримуються. Криптопровайдер Microsoft має тип 1, цей тип провайдера реалізує в якості алгоритмів цифрового підпису та обміну ключів алгоритм RSA. Інший базовий криптопровайдер Microsoft, "Microsoft Base DSS and Diffie-Hellman Cryptographic Provider", має тип 13. Цей тип криптопровайдера реалізує алгоритм цифрового підпису DSS, а в якості алгоритму обміну ключами – протокол Діффі-Хелмана.
Отже, для роботи з набором криптопровайдерами у системному реєстрі міститься список імен усіх криптопровайдерів. З кожним ім‘ям пов‘язаний тип криптопровайдера та ім‘я бібліотеки, яка реалізує його алгоритми.
Окрім цього в системі міститься інформація про те, який криптопровайдер треба застосовувати, якщо користувач явно не вказав конкретне його ім‘я, лиш
Тепер розглянемо, яким чином користувач починає працювати з конкретним криптопровайдером, і як система викликає конкретну бібліотеку, що відповідає обраному криптопровайдеру.
Принцип захисту за допомогою PIN ґрунтується на тому факті, що ніхто, окрім власника картки, не знає цього коду. Тому вимоги до PIN такі:
- він не повинен зберігатися у відкритому вигляді;
- PIN не можна отримати на основі інформації на магнітній стрічці або бази даних.
Зазвичай, PIN - це 4-значне число, але зараз зустрічаються і 5-значні PIN-коди.
Загрози безпеці інформації з боку шахраїв призвело до необхідності введення додаткової аутентифікації карток відносно платіжної системи, так званого числа перевірки картки (Card Verification Value). CVV – це складна для обчислення послідовність цифр, яка створюється зашифруванням певної інформації. CVV записано на магнітну стрічку картки, так що збирання візуальної інформації про власника картки та власне про картку нічого зловмисникові не дає.
Для утворення CVV комбінуються статичні дані, наприклад, номер рахунку, тричі шифрується на ключах Card Verification. З утвореного результату обираються цифри для створення CVV та записуються на магнітну стрічку.
Отже, CVV надає додатковий рівень захисту картки від підробки. Треба мати на увазі, однак, що цей спосіб не захищає від такої атаки, як збирання даних про картки за допомогою фальшивих банкоматів.
Існує ще один варіант CVV - CVV2, який використовується для авторизації телефоном. Він розраховується приблизно за таким самим алгоритмом, як і CVV, а результат друкується на звороті картки. Ці цифри можуть запитувати при виконанні трансакцій по телефону для перевірки легітимності операції.
Для підтримки PIN виконуються такі обчислення:
- Генерується 4-значне число - це PIN;
- PIN комбінується з іншою інформацією, наприклад, з номером рахунку, щоб створити блок даних для процесу шифрування;
- Цей блок тричі шифрується на робочих ключах PIN;
- З отриманого результату обираються деякі цифри. Вони і є Pin Verification Value (Число Перевірки PIN) або Pin Offset (Зміщення PIN);
- Зміщення PIN зберігається;
- Друкується захищений конверт з PIN;
- Пам’ять очищується нулями, щоби приховати усі сліди існування PIN.
На цьому етапі єдине місце, де знаходиться відкрите значення PIN – це конверт, а сам PIN не можна отримати зі зміщення PIN.
Коли картка використовується, власник вводить PIN-код, а зміщення обчислюється та порівнюється з тим, що зберігається у базі даних комп’ютера. Отже і у цьому разі PIN-код не передається мережами у відкритому вигляді.
Ще раз підкреслюємо, що зміщення складається з цифр, які вибрано з шифрованих даних. Зазвичай це 4-6 цифр, знаючи які неможливо відновити власне PIN.
Робота з певним провайдером починається з виклику функції CryptAcquireContext, де користувач визначає тип потрібного криптопровайдера, його назву та назву робочого ключового контейнера. В результаті роботи функція повертає користувачу дескриптор криптопровайдера (handle), за допомогою якого користувач в подальшому буде звертатися до нього та передавати його у процедури для виконання усіх необхідних криптографічних операцій.
Детальний опис контексту роботи з криптопровайдерами та приклади (мовою програмування С) дивіться у книжці Щербакова Л.Ю., Домашева А.В. "Прикладная криптография".
Власне бібліотеки CryptoAPI разом з файлами заголовків та допомоги постачаються у складі бібліотек MSDN.
Відомості про способи аутентифікації.
Однією з основних функцій систем захисту від несанкціонованого доступу є ідентифікація та аутентифікація. Вона полягає в тому, що жоден суб’єкт (сутність обчислювальної системи, здатна ініціювати виконання операцій) не може отримати доступ до об’єктів (сутностей обчислювальної системи, що захищаються) без надання системі захисту певного обсягу інформації про себе.
При цьому ідентифікація
суб’єкта полягає в тому, що суб’єкт повідомляє системі захисту свій унікальний ідентифікатор в обчислювальній системі; аутентифікація
суб'єкта полягає в тому, що суб’єкт надає системі захисту окрім ідентифікуючої інформації ще й певну інформацію, за допомогою якої система перевіряє, що він дійсно є тим суб’єктом, якого стосується ідентифікуюча інформація; авторизація
суб’єкта відбувається після вдалих ідентифікації та аутентифікації і полягає в тому, що обчислювальна система виконує дії, необхідні для того, щоб суб’єкт мав можливість почати роботу.
Таким чином, щоб отримати доступ в обчислювальну систему, користувач має спочатку ідентифікувати себе, а механізми захисту, в свою чергу, мають підтвердити істинність користувача, тобто підтвердити, що він дійсно є тим, кого з себе удає. Існує три групи способів підтвердження істинності користувача. Відповідно, для кожної групи механізми підсистеми ідентифікації та аутентифікації мають перевірити:
1)щось, що користувач знає
(паролі, ідентифікаційні коди, інші відомості);
2)щось, що користувач має
(ключі, магнітні чи смарт-картки і т.п.);
3)щось, чим користувач є
(особисті характеристики користувача: відбитки пальців, малюнок сітківки ока, характеристики голосу, особливості користування клавіатурою та маніпуляторами).
Далі розглядатимуться способи, що належать до першої групи, як найбільш поширені.
Якщо перевіряється істинність тільки користувача, то таку процедуру називають одностороннім (peer-entity) підтвердженням істинності. В іншому випадку, тобто коли користувач має підтвердити свою істинність системі, а система, в свою чергу, має підтвердити свою істинність користувачеві, така процедура носить назву двосторонньої (peer-to-peer) аутентифікації.
В разі використання аутентифікації за простим паролем
кожен користувач обчислювальної системи отримує пару значень – ідентифікатор (ім'я в системі) та пароль. Користувач отримує доступ, якщо вказаний ним в процесі входу в систему ідентифікатор є зареєстрованим, а відповідний пароль – вірним.
Така схема вразлива щодо втрати або розголошення пароля, внаслідок чого одні користувачі можуть видавати себе за інших, тим самим здійснюючи несанкціонований доступ.
Іншим способом є аутентифікація на основі списку паролів
. При цьому користувачеві разом з ідентифікатором надається список паролів. Перший пароль використовується при першому входів систему, другий – при другому і т. д. Незважаючи на те, що така схема є більш стійкою до втрати окремих паролів, вона має суттєві недоліки, а саме:
○ користувачеві незручно запам'ятовувати список паролів;
○ у випадку помилки або збою при аутентифікації користувач не знає, користуватись йому поточним чи наступним паролем.
Ще одним способом аутентифікації є метод одноразових паролів
.
Під час реєстрації користувач генерує певну послідовність, наприклад:
F999
(x), …, F(F(F(x))), F(F(x)), F(x), x,
де х – випадкове число.
При цьому в системі в цей час зберігається значення F1000
(x), на першому кроці в якості паролю користувач використовує значення F999
(x). Отримавши його, система обчислює F(F999
(x)) та перевіряє його на відповідність тому F1000
(x), що зберігається. В разі відповідності користувач отримує доступ до системи, а в системі в якості поточного зберігається вже значення F999
(x). На другому кроці перевіряється F(F998
(x)) = F999
(x) і так далі. Таким чином, пароль, що вже був використаний, а також всі інші, що знаходяться у списку перед ним, стають недійсними. При цьому у випадку порушення синхронізації користувач має можливість перейти до наступного в списку значення, або навіть "перескочити" через один чи кілька паролів, а система вираховує F(F(…Fn
(x)…)) поки не отримає значення, відповідне тому, що зберігається. Перевірити істинність користувача також можна за допомогою методу рукостискання
(handshake). При цьому існує процедура f, що відома лише користувачеві та обчислювальній системі. При вході в систему генерується випадкове значення х і обчислюється f(x). Користувач, отримавши х, також обчислює y = f(x) та надсилає його системі. Система порівнює власне значення з отриманим від користувача і робить висновок про його (користувача) істинність. При використанні методу рукостискання ніякої конфіденційної інформації між користувачем і обчислювальною системою не передається взагалі, навіть у шифрованому вигляді. Щодо самої функції f(x), то вона має бути досить складною, щоб зловмисник не міг її вгадати, навіть накопичивши велику кількість пар (x, f(x)). В якості процедури f(x) можна використовувати шифрування x на таємному ключі, який є спільним секретом (або шифрування таємного "магічного рядка" на ключі x). Ключова послідовність генерується системою при так званій ініціалізації ключа. В сеансі ініціалізації ключ записується у файл. Після цього генерований ключ можна використовувати для криптографічних цілей.
Подальша робота з зашифрованим логічним диском звичайна, як зі звичайним логічним диском Windows.
Фізично створений диск являє собою звичайний файл на диску, який виступає логічним диском після монтування його в систему. При монтуванні система питає пароль і, якщо вказано, ключовий файл.
Якщо диск не підмонтований в систему, він виступає як файл. Його можна скопіювати, знищити і т.ін., але прочитати інформацію, яка зберігається в ньому, можна лише знаючи ключ.
Насичення інформаційно-комунікаційних мереж різного роду послугами неможливе без широкого використання без паперових технологій: від оплати різних послуг (комунальні платежі, послуги провайдерів, банківські послуги і т.д.) та надання фінансової звітності (податкові декларації, баланси організацій і т.д.), до організації систем електронної торгівлі, керування рахунками у банках, замовлення білетів, послуг і т.ін. Такі технології вимагають використання безпечних механізмів обміну юридично важливою інформацією. Основою безпечного використання електронного документообігу у відкритих комп‘ютерних мережах є:
- необхідність гарантованого підтвердження особи абонента, що відправив електронний документ;
необхідність гарантованого підтвердження того, що документ обов‘язково буде отримано лише вказаним адресатом;
- необхідність гарантованого підтвердження того, що під час передавання мережами зв‘язку, в документ не внесено ніяких змін.
Ці вимоги можна задовольнити лише за допомогою спеціалізованого програмного забезпечення.
Література
1. Галицкий А.В., Рябко С.Д., Шаньгин В.Ф. Защита информации в сети. – М.:ДМК Пресс, 2004.
2. Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа. – СПб.:Наука и техника, 2004.
3. Проскурин В.Г., Крутов С.В., Мацкевич И.В. Защита в операционных системах. – М.: "Радио и связь", 2000.
4. Щербаков А, Домашев А. Прикладная криптография. Использование и синтез криптографических интерфейсов. М.:Русская редакция, 2003.
5. М.А.Деднев, Д.В.Дыльнов, М.А.Иванов Защита информации в банковском деле и электронном бизнесе. М.:Кудиц-образ, 2004. – 512 с.