1. Проблема аутентифікації доступу до інформаційних ресурсів є на сьогодні досить актуальною. Захисту...
2. Інтерактивний вхід в систему
3. Запит на вхід в систему
4. Перевірка сертифіката
5. Перевірка цифрового підпису
6. Пошук облікового запису і квиток TGT
7. Автономна реєстрація в системі (Offline Logon)
8. аутентифікація клієнта
9. взаємна аутентифікація
10. авторизація
11. Віддалений доступ
12. політики безпеки
13. Персональні ідентифікаційні номери
14. Станція реєстрації eToken
15. впровадження eToken
16. Познайомимося ближче
17. eToken R2
18. eToken Pro
19. eToken RIC
20. Переваги eToken перед смарт-картами

Проблема аутентифікації доступу до інформаційних ресурсів є на сьогодні досить актуальною. Захисту за допомогою пароля нерідко виявляється недостатньо, її потрібно посилювати. Операційна система Microsoft Win-dows 2000 дозволяє удосконалити процес аутентифікації користувачів за допомогою смарт-карт, але при цьому потрібна наявність пристрою читання - рідера. Є й інші варіанти, і один з них передбачає використання електронних USB-ключів eToken компанії «Аладдін», які є повнофункціональним аналогом одновременнно смарт-карт і пристроїв читання / запису для роботи зі смарт-картами.

Смарт-карта або eToken

Термін «смарт-карта» використовується для позначення пристроїв розміром з кредитну картку, що володіють різними можливостями: карти для зберігання даних, безконтактні карти і карти на основі інтегральних мікросхем (integrated circuit cards, ICC). Всі вони відрізняються один від одного, а також від традиційних карт із магнітною смугою, зазвичай використовуваних для обслуговування банківського рахунку.

На персональному комп'ютері і в середовищі Windows 2000 використовуються карти на основі інтегральних мікросхем, так як вони можуть виконувати складні криптографічні операції. Смарт-карта - це, по суті, мініатюрний комп'ютер з обмеженою пам'яттю і можливістю обробки даних, укладений в форму пластикової кредитної картки. Обмін даними між смарт-картою та додатком, що працює на комп'ютері, здійснюється через напівдуплексний послідовний інтерфейс, керований на приймальний пристрій за допомогою відповідного драйвера. Пристрої для читання смарт-карт досить різноманітні і можуть приєднуватися до комп'ютера за допомогою інтерфейсу RS-232, PCMCIA або USB.

eToken - це перший повнофункціональний аналог смарт-карти, виконаний у вигляді брелока. Він безпосередньо підключається до комп'ютера через порт Universal Serial Bus (USB) і не вимагає наявності дорогих пристроїв зчитування або інших додаткових пристроїв. Більш детальна інформація про моделі eToken приведена у виразках "Познайомимося ближче" і «Переваги eToken перед смарт-картами» .

Смарт-карти є найважливішим компонентом інфраструктури відкритих ключів (PKI), інтегрованої Microsoft в Windows 2000. Смарт-карти розширюють можливості програмної аутентифікації. Аналогічними функціями володіє і eToken, який забезпечує:

• фізичне сховище сертифікатів, надійно захищене від злому;
• ізоляцію криптографічних операцій з особистими ключами від операційної системи;
• можливість використання одних і тих же сертифікатів і ключів на роботі, вдома або в іншому місці за рахунок мобільності фізичного сховища.

eToken може використовуватися для аутентифікації користувача в домені Windows 2000 в трьох випадках:

• інтерактивний вхід в систему (interactive logon), при якому задіюються каталог Active Directory, протокол Kerberos версії 5 і сертифікат відкритого ключа;
• віддалений вхід в систему (remote logon), який використовує сертифікат відкритого ключа, протокол Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) для ідентифікації віддаленого користувача, обліковий запис якого зберігається в каталозі Active Directory;
• аутентифікація клієнта (client authentication) - процес взаємної ідентифікації користувача і домена за допомогою сертифіката відкритого ключа, сопоставленного з зберігається в каталозі Active Directory обліковим записом.

Користувачам, які не займаються адмініструванням, простіше носити з собою eToken, а не запам'ятовувати паролі. До цієї категорії користувачів зазвичай відноситься значна частина службовців компанії. Такими користувачами можуть бути позаштатні співробітники, постачальники, підрядники та всі, кому не доводиться управляти комп'ютером або мережею.

Оскільки eToken може застосовуватися для ідентифікації по SSL на додаток до інтерактивної та дистанційної реєстрації, ефект від впровадження eToken буде ще більше, так як значної частини персоналу не доведеться використовувати паролі. Однак користувачам з розширеними повноваженнями і адміністраторам доводиться виконувати операції, які передбачають вторинну аутентифікацію із запитом імені користувача, імені домена і пароля, і, отже, тут eToken не підійде. Зокрема, eToken не може застосовуватися при операціях включення комп'ютера в домен, установці або видаленні Active Directory, налаштування служби віддаленого доступу.

Інтерактивний вхід в систему

При підключенні eToken до USB-порту Windows 2000 «розуміє», що тепер, замість імені користувача, імені домена і пароля, необхідно запросити персональний ідентифікаційний номер (Personal Identification Number, PIN), см. Екран 1. Ця подія еквівалентно натискання клавіш Ctrl -Alt-Del, який ініціює процедуру входу в систему з використанням пароля. Однак PIN, який вказується в діалоговому вікні при вході в систему, забезпечує аутентифікацію тільки по відношенню до eToken, але не до домену.

Сертифікат відкритого ключа, що зберігається в захищеній пам'яті eToken, використовується для аутентифікації в домені із застосуванням протоколу Kerberos версії 5 і його розширення PKINIT.

Запит на вхід в систему

Після того як користувач вводить у вікні реєстрації PIN, операційна система визначає, чи може користувач бути ідентифікований та аутентифікований на основі пред'явленої їм засвідчує інформації (PIN і eToken). При запиті на вхід в систему спочатку відбувається звернення до локальної системі безпеки (LSA), яка передає запит пакету аутентифікації Kerbe-ros, запущеного на клієнтському комп'ютері. Пакет Kerberos надсилає запит службі аутентифікації Key Distribution Center (KDC), що функціонує на контролері домену, для аутентифікації і отримання квитка TGT (квиток початкового рівня - Ticket Granting Ticket). До складу запиту до служби аутентифікації (Authentication Service, AS), в ті його поля, які передують ідентифікаційним, поміщається сертифікат користувача, виявлений в пам'яті eToken. Посвідчення, яке включене в ці поля, завіряється підписом з використанням особистого ключа користувача так, щоб KDC могла перевірити запит, відправлений власником сертифікату.

Перевірка сертифіката

Перед тим як задовольнити запит, служба AS, перш за все, повинна перевірити походження сертифіката і переконатися в тому, що він заслуговує на довіру. KDC використовує CryptoAPI, щоб простежити шлях від призначеного для користувача сертифіката до сертифікату кореневого центру сертифікації (CA). Якщо KDC з тих чи інших причин (наприклад, кореневий сертифікат недійсний, неможливо знайти батьківські сертифікати або визначити, чи не анульований сертифікат) виявиться не в змозі побудувати допустиму ланцюжок сертифікатів, то вона поверне повідомлення про помилку і відмовить в задоволенні запиту.

KDC також повинна перевірити, чи уповноважений центр сертифікації, що видав сертифікат, видавати сертифікати для аутентифікації в домені. У Windows 2000 для аутентифікації за допомогою eToken джерелом сертифікатів повинен бути корпоративний центр сертифікації, який опублікований в Active Directory. Це потрібно для запобігання видачі сертифікатів в просторі імен іншого домену помилковими центрами сертифікації, дійсними тільки в одній з ієрархій. Хоча зробити подібного роду атаку виключно складно, так як це залежить від отримання помилковим центром сертифікації прав на видання від законного батьківського центру сертифікації, рішення запитувати корпоративний CA, опублікований в Active Directory, було прийнято з метою уникнення самої можливості вторгнення.

Перевірка цифрового підпису

Після успішної перевірки сертифіката користувача служба KDC застосовує CryptoAPI для перевірки цифрового підпису посвідчення. Перевірка підпису виконується за допомогою відкритого ключа з призначеного для користувача сертифіката для підтвердження того, що запит виходить від власника відкритого ключа. Оскільки сертифікат був виявлений в захищеній пам'яті eToken, а посвідчення підписано з використанням особистого ключа, що зберігається знову ж в eToken, цифровий підпис має бути законна. Після перевірки підпису служба KDC повинна перевірити позначку часу в посвідченні, щоб переконається в тому, що запит не є атакою, що використовує перехоплені в мережі дані.

Пошук облікового запису і квиток TGT

Переконавшись, що користувач є тим, за кого себе видає, і що сертифікат може бути використаний для аутентифікації в домені, служба KDC запитує в каталозі домену обліковий запис. KDC шукає обліковий запис користувача в Active Directory за основним імені користувача (User Principal Name, UPN), яке зазначено в поле альтернативного імені (Subject Alternative Name) в призначеному для користувача сертифікаті відкритого ключа. Обліковий запис, яку KDC отримує від служби каталогу, використовується для формування квитка TGT. Квиток TGT включатиме ідентифікатор безпеки користувача (Security ID, SID), SID всіх груп, членом яких користувач є. Список SID внесений в поля даних авторизації TGT.

KDC генерує спеціальний сеансовий ключ для захисту подальшої взаємодії клієнта з контролером і поміщає його в створений квиток TGT. Потім KDC шифрує TGT, використовуючи спеціальний ключ, що зберігається в облікового запису krbtgt. Сеансовий ключ зашифрована за допомогою відкритого ключа із сертифіката користувача і включається у відповідне поле відповіді KDC. Служба KDC підписує відповідь, використовуючи свій особистий ключ, щоб клієнт був упевнений, що відповідь отримана від KDC, якій можна довіряти.

Клієнт спочатку перевіряє підпис KDC, формуючи шлях сертифікації від сертифіката KDC до довіреній кореневого CA, а потім використовує відкритий ключ KDC, щоб перевірити підпис відповіді. Після отримання відповіді KDC клієнт за допомогою свого особистого ключа розшифровує сеансовий ключ. Отриманий TGT надалі використовується вже стандартним протоколом Kerberos для запитів сеансових квитків для доступу до ресурсів домена.

Автономна реєстрація в системі (Offline Logon)

Коли користувач відключений від джерела або контролер домену недоступний, користувач повинен зберегти можливість зареєструватися на своєму комп'ютері автономно. Така можливість забезпечується за допомогою паролів шляхом порівняння хешировать пароля, що зберігається локальною системою безпеки, з хешем посвідчення, яке користувач пред'являє Graphical Identification and Authentication (GINA) в процесі автономної реєстрації в системі. Якщо порівнювані дані збігаються, користувач отримує доступ до локальної машині.

У разі застосування eToken автономний вхід в систему вимагає ввести особистий ключ користувача для розшифровки додаткових посвідчень, зашифрованих за допомогою відкритого ключа користувача. Якщо у користувача є кілька ключів eToken, додаткові посвідчення повинні бути розшифровані і співвіднесені з хешем посвідчення для того, щоб гарантувати користувачеві можливість доступу незалежно від того, який eToken використовується.

аутентифікація клієнта

Оскільки підтримка eToken інтегрована в CryptoAPI, протоколам Secure Sockets Layer (SSL) і Transport Layer Security (TLS) не потрібно «знати» що-небудь про eToken для того, щоб працювати з ним. Роль eToken в процесі аутентифікації клієнта полягає в тому, щоб підписати частина даних протоколу на початковій стадії сеансу обміну даними по протоколу SSL. Оскільки закритий ключ, відповідний сертифікату відкритого ключа, зберігається в пам'яті eToken, подібний метод аутентифікації є більш суворим, так як застосування закритого ключа вимагає від власника eToken підтвердження прав доступу і до eToken, і до домену. Крім того, операції з закритим ключем, що виконуються на початковій стадії сеансу обміну даними, реалізуються eToken таким чином, що закритий ключ ніколи не передається комп'ютера або в локальну мережу.

взаємна аутентифікація

Обидва протоколу, SSL 3.0 і TLS 1.0, підтримують взаємну аутентифікацію, що для клієнта означає можливість перевірити справжність сервера, а для сервера - справжність клієнта.

Аутентифікація сервера відбувається, коли клієнт підтверджує справжність сервера, перевіряючи криптографічний підпис в сертифікаті сервера, а також всіх проміжних сертифікатів CA.

Аутентифікація клієнта сервером реалізована так само, як і аутентифікація сервера, але перевірка сертифікатів здійснюється в протилежному напрямку. Сервер перевіряє криптографічний підпис в сертифікаті клієнта, а також всі проміжні сертифікати CA.

Як тільки аутентифікація клієнта виконана, сервер повинен встановити контекст безпеки з відповідною авторизацією, яка визначає, які ресурси сервера дозволено використовувати клієнту.

авторизація

При аутентифікації клієнта в Win-dows 2000 с застосуванням відкритих ключів використовуються дані з сертифіката клієнта для отримання інформації про його права доступу в домені.

Коли встановлено сеанс SSL або TLS, провайдер безпечного каналу (secure channel provider) перш за все намагається, виходячи з UPN сертифіката, знайти обліковий запис користувача в каталозі домену. UPN включено в сертифікат у поле альтернативного імені суб'єкта (Alternative Subject Name), воно визначає точне ім'я облікового запису користувача (префікс) і ім'я домену, в якому розташована обліковий запис (суфікс). Так само як при вході в систему за допомогою eToken на основі Kerberos, джерело сертифікатів повинен мати повноваження на випуск сертифікатів для домену, щоб їм можна було довіряти при ідентифікації і перевірки повноважень.

Якщо немає відповідності UPN або СА не уповноважений видавати сертифікати для аутентифікації в домені, провайдер намагається запросити в каталозі пошук облікового запису, у якій атрибут Alternate Security Iden-tities містить явне вказівку на відповідність сертифікату клієнта. Явна вказівку сертифіката в облікового запису користувача вимагає додаткових дій з боку пекло міністратора. Відповідність сертифікату клієнта може бути засноване або на імені джерела, або на джерелі і суб'єкті в сертифікаті. Обліковий запис може мати один або більше пов'язаних з нею сертифікатів, що спрощує застосування одного облікового запису кількома користувачами. Сертифікат не може відповідати декільком облікових записів, що зберігаються в каталозі домену. Аутентифікація нічого очікувати виконано, якщо сертифікат відповідає більш ніж один обліковий запис.

Віддалений доступ

Підтримка розширюється аутентифікації для віддалених користувачів в Windows 2000 забезпечується службою віддаленого доступу RAS. Сервер віддаленого доступу підтримує протокол аутентифікації EAP і забезпечує модулів різних виробників можливість підтримки різноманітних методів аутентифікації (див. Екран 2).

Windows 2000 містить вбудований модуль для підтримки eToken, що дозволяє забезпечити сувору аутентифікацію віддалених користувачів. Зауважу, що віддалений доступ до системи фактично означає дві аутентифікації: на сервері RAS і в мережі.

Перша аутентифікація завершується підтвердженням аутентифікації сер-віра RAS клієнтом і встановленням з'єднання між клієнтом і сервером. В результаті клієнтові зіставляються деякі політики RAS і атрибути облікового запису. Атрибути облікового запису застосовуються індивідуально і включають такі властивості, як права доступу, режими зворотного виклику (callback options), статичні маршрути (static routes) і т. Д. Політики RAS визначають основні принципи взаємодії сервера з клієнтом. Це дозволяє управляти користувачами, забезпечуючи відповідність властивостей підключення, групового членства, профілю і т. Д.

Друга аутентифікація відноситься до домену і використовує TLS в якості протоколу аутентифікації замість Kerberos. Аутентифікація в домені з використанням EAP-TLS дуже схожа на аутентифікацію по протоколу SSL, за винятком того, що сертифікат відкритого ключа повинен містити UPN, відповідне облікового запису, що зберігається в доменному каталозі Active Directory.

політики безпеки

В домені Windows 2000 є кілька типів політик, що визначають процедури роботи з eToken.

Обов'язкове використання eToken. Windows 2000 підтримує на рівні окремого користувача політику облікових записів, що вимагає обов'язкового використання eToken для інтерактивної реєстрації в системі (див. Екран 3).

Це означає, що, як тільки політика застосована до облікового запису, скористатися паролем для інтерактивної реєстрації або реєстрації з командного рядка буде неможливо. Політика діє тільки для інтерактивної реєстрації в мережі, але не для віддаленого доступу, коли використовується інша політика, встановлена ​​на сервері віддаленого доступу.

Режим обов'язкового використання eToken, обумовлений політикою облікового запису при інтерактивній реєстрації, повинен бути встановлений для користувачів, які є членами групи Users і застосовують eToken для реєстрації в домені Windows 2000.

Від'єднання eToken. Коли користувач надовго відходить від комп'ютера в ході розмови виникла, передбачається, що він або виходить з системи, або блокує комп'ютер. В іншому випадку комп'ютер відкритий для зловмисника, який має фізичний доступ до нього.

Політика вилучення смарт-карти (або eToken) - це локальна політика, дія якої поширюється на комп'ютер, а не на обліковий запис користувача.

Рішення про встановлення політики від'єднання eToken Залежить від потреб корпорації и від того, як Користувачі Працюють з комп'ютерами. У тих ситуаціях, коли робота ведеться в приміщеннях, куди можуть зайти сторонні, використання такої політики настійно рекомендується (див. Екран 4). Якщо ж у кожного користувача є окремий комп'ютер, можливо, немає необхідності встановлювати вищеописану політику, і можна обмежитися застосуванням зберігачів екрану і тому подібних заходів.

Як і у випадку багатьох інших політик безпеки, посилення захисту пов'язане з додатковими незручностями в роботі.

А що робити, якщо користувач забув свій eToken будинку? Можливість увійти в будівлю по тимчасовому пропуску істотно відрізняється від того, що потрібно для реєстрації на комп'ютері для виконання службових обов'язків. Тут може бути кілька варіантів.

Можна видати тимчасовий eToken з сертифікатом короткого терміну дії, наприклад на один день.

Або ж можна не встановлювати політику обов'язкового використання eToken для інтерактивної реєстрації, а замість неї встановити політику, що вимагає використання довгого пароля, який видається користувачам тільки в крайньому випадку, а згодом скасовується.

Персональні ідентифікаційні номери

У той час як паролі мають очевидними недоліками, зокрема створюються користувачами на основі легко запам'ятовуються асоціацій, PIN-коди eToken не підкоряються тим же правилам, що і «надійні паролі» (strong passwords), оскільки eToken не схильні до класичним атакам шляхом підбору слів.

Проблеми запам'ятовування PIN-коду не існує, оскільки eToken блокує багаторазові спроби ввести хибний PIN-код, апаратно реалізуючи затримку (приблизно 1 с) між вводами PIN-коду.

Оскільки PIN-код ніколи і ні в якій формі не передається безпосередньо по мережі, атаки з використанням перехопленої інформації надзвичайно утруднені необхідністю фізично володіти самим ключем eToken (на відміну від імітації мережевого пакету при атаках, що базуються на паролі).

Завдяки здатності eToken протистояти вищеописаним типам атак, часто міняти PIN-код не потрібно.

Станція реєстрації eToken

Станція реєстрації смарт-карт (те ж саме відноситься і до eToken) працює як частина корпоративної служби центру сертифікації в Windows 2000 Server і Windows 2000 Advanced Server. Вона підтримує централізовану видачу eToken. Станція реєстрації смарт-карт використовує шаблони сертифікатів для визначення того, яку інформацію включати в той чи інший сертифікат.

Для eToken існує два шаблони:

• eToken для реєстрації (не може використовуватися для захисту електронної пошти);
• eToken користувача.

Щоб видавати сертифікати для eToken, на підприємстві повинна існувати станція реєстрації смарт-карт (eToken). Ця вимога обов'язково, оскільки за замовчуванням користувачі домену не можуть реєструвати сертифікати eToken, видані корпоративним ЦС Windows 2000.

Доступ до сертифікатів eToken обмежений адміністратором домену, якщо тільки він не модифікував права доступу до шаблонів, щоб забезпечити іншим групам користувачів можливість реєстрації. Це необхідно для запобігання атак в тому випадку, коли користувач залишає своє робоче місце, не завершивши сеансу роботи з системою або не заблокований її, і хтось використовує активний сеанс для реєстрації сертифіката eToken під виглядом користувача (можливо, не підозрює про це).

Для використання станції реєстрації eToken Windows 2000, хтось із співробітників повинен виконувати функції реєстратора. Для того щоб підтримати ці функції, корпоративний центр сертифікації може видати такому працівникові сертифікат реєстратора. Даний сертифікат забезпечує більш широкі повноваження в порівнянні з іншими, оскільки службовець з сертифікатом реєстратора має можливість зареєструвати сертифікат eToken будь-якого користувача домену, включаючи адміністратора. Тому рекомендується, щоб за замовчуванням права доступу до шаблону сертифіката реєстратора надавали можливість реєстрації лише обраним співробітникам.

Крім того, бажано відключити видачу сертифіката цього типу в центрі сертифікації, за винятком особливих випадків або коли необхідно автономне (offline) застосування CA. За замовчуванням, дозволи на доступ до сертифікатів реєстраторів встановлені тільки для адміністраторів доменів.

впровадження eToken

Використання в організації eToken дозволяє істотно підвищити безпеку мережі за рахунок вдосконалення методів аутентифікації. До того ж користувачам більше не доведеться запам'ятовувати безліч облікових записів (login) і паролів до різних ресурсів мережі і додатків. Потрібно запам'ятати одне-єдине число - PIN-код до свого ключу eToken.

Максим Підлісний - керівник відділу розробок компанії Aladdin Software Security RD C ним можна зв'язатися за адресою: [email protected] .

Познайомимося ближче

eToken має до 64 Кбайт захищеної незалежній пам'яті (EEPROM) і може використовуватися як портативний контейнер для зберігання секретних даних (ключів шифрування, кодів доступу, сертифікатів). eToken має унікальний серійний номер (ID) і може використовуватися як електронний ідентифікатор (ключ) для аутентифікації користувача. eToken підтримує роботу і інтегрується з усіма основними системами і додатками, що використовують технологію Public Key Infrastructure (PKI).

eToken R2

eToken R2 має апаратно реалізований алгоритм шифрування DESX зі 120-розрядним ключем.

eToken Pro

eToken Pro, на відміну від R2, має додатковий чіп смарт-карти, апаратно реалізує алгоритм шифрування RSA / 1024, 3DES (TripleDES), SHA-1 і генератор особистих (Private) ключів, ніколи не покидають мікросхему.

У eToken Pro використовується мікросхема SLE66C Infineon, що забезпечує виключно високий рівень безпеки, сертифікований по ITSEC LE4.

У eToken Pro використовує файлову систему Siemens CardOS / M4, що підтримує необмежену ієрархію об'єктів і файлів.

eToken RIC

У eToken RIC апаратно реалізовані криптографічні алгоритми шифрування ГОСТ 28147-89 (має сертифікат відповідності ФАПСИ), включаючи диверсифікацію і формування сесійного ключа, а також DES і Triple DES.

назад

Переваги eToken перед смарт-картами

Крім функцій смарт-карт eToken володіє додатковими можливостями:

• не вимагає дорогого пристрою зчитування і зайвих проводів. Більшість пристроїв читання смарт-карт підключається до комп'ютера через послідовний порт RS-232, роз'єм PCMCIA Type II або шину USB. eToken безпосередньо підключається до комп'ютера через USB-порт і не вимагає наявності дорогих пристроїв зчитування або інших додаткових пристроїв;
• має більше пам'яті (до 32 Кбайт) і може зберігати кілька сертифікатів (сім і більше). Криптографічні смарт-карти мають обмежений обсяг пам'яті, зазвичай від 2 до 16 Кбайт. Оскільки пам'ять користується великим попитом і досить дорого коштує, виробники карт обмежують обсяг пам'яті, доступний одному з додатком;
• різні додатки можуть використовувати один і той же eToken. eToken підтримує стандарт PC / SC і емулює смарт-карту і пристрій зчитування, що дозволяє легко вбудовувати його як в існуючі програми, так і в нові. При роботі з різними додатками може використовуватися вже наявний eToken. Необхідності в покупці додаткових ключів немає. Буде потрібно лише доплатити за ліцензію на використання потрібної програми;
• можлива одночасна робота з декількома брелоками eToken.

назад