Протокол KERBEROS

Приклад роботи.NET Reflector

Головне вікно.NET Reflector показує список збірок із складу.NET Framework. Про кожну із них можна подивитися інформацію, а також переглянути списки класів і тонкощі реалізації кожної із них.

Для демонстрації можливостей декомпілятора, відкриємо виконуваний файл популярного графічного редактору Paint.NETі переглянемо код методу PainDotNet.Tools.FloodToolBase, який, судячи з назви відповідає за заливку зображення деяким кольором.

Код програми можна дизасемблювати не тільки в C#, але й в MSIL, VB.NET, Delphi, MC++.

Як легко бачити із вищенаведеного прикладу, декомпіляція і дослідження коду.NETпрограм є дуже простим завданням навіть для мало кваліфікованого користувача. Виходячи з цього, постає проблема захисту програмного коду створеного за допомогою технології.NETFramework. Особливо це актуально для програм, що розповсюджуються на комерційній основі.

Способи захисту коду.NETпрограм від дослідження

Розглянемо методи захисту.NET збірки від дослідження:

· Обфускація коду програми. Цей метод є найбільш простим і поширеним.

· Компіляція збірки у машинний (native)код при його встановленні на комп’ютер користувача. Зокрема, це можна виконати з допомогою утиліти ngen, яка поставляється у комплекті із.NETFramework.Але, цей метод може призвести до деяких непередбачуваних наслідків, наприклад, при встановленні нової версії.NETFramework, програма, встановлена таким чином, може припинити працювати.

· Використання оптимізуючих компіляторів.

· Розроблення критичних частин програмного коду на ManagedC++, що дещо ускладнить процес декомпіляції.

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

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

Протокол Kerberos (з англ. Цербер), орієнтований в основному на клієнт-серверну архітектуру, пропонує механізм взаємної аутентифікації двох співрозмовників (хостів) перед встановленням зв'язку між ними в умовах незахищеного каналу. Kerberos - це також пакет вільного програмного забезпечення розробленого в Массачусетському технологічному інституті, що реалізовує цей протокол. Повідомлення протоколу Kerberos захищені проти прослуховування мережі та повторних атак (англ. replay attack).

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

Історія і розвиток

Протокол Kerberos розроблявся інститутом MIT для забезпечення безпеки сервісів проекту Афіна, метою якого було забезпечення доступності навчальних матеріалів із будь-якої станції. Назва протоколу походить від грецької міфічної триголової потвори Цербера, захисника підземного царства. Існує декілька версій протоколу Включно із третьою були доступні лише для внутрішнього користування у МІТ.

Стів Міллер (англ. Steve Miller) та Кліффорд Ньюман (англ. Clifford Neuman), основні архітектори четвертої версії Kerberos, опублікували її у кінці 1980-х, хоча вона також розроблялась в основному для проекту Афіна. П'ята версія протоколу, розроблена Джоном Колем (англ. John Kohl) та Кліффордом Ньюманом, з'явилась у 1993 році як рекомендація на стандарт RCF 1510, оновлена 2005 року у RCF 4120.

Ранні версії Kerberos (c 1 по 3) були створені всередині МIT і використовувалися в цілях тестування. Ці реалізації містили істотні обмеження і були корисні тільки для вивчення нових ідей і виявлення проблем, які могли виникнути під час розробки.

Дата добавления: 2014-12-25