Протягом тисячоліть люди використовували різні методи для приховування інформації, що передається, а також перевірки відправника і повідомлення. У міру розвитку цивілізації був створений і отримує тепер широке поширення єдиний метод для виконання всіх цих трьох завдань. протокол
S / MIME - це система безпечної відправки електронної пошти з використанням шифрування і цифрового підпису.
Поточні технології шифрування (закриття) діляться на два основних типи: алгоритми з симетричними (секретними) ключами, такі як стандарт DES або AES, і алгоритми з асиметричними (відкритими / закритими) ключами, такі як RSA або ECC. Сучасні засоби перевірки відправника - це математичні односторонні функції, іменовані хеш-кодами, які створюють унікальні підписи. Два часто використовуваних методу хешування - це алгоритми MD5 і SHA. Комп'ютери можуть використовувати їх для створення унікального хеш-коду або номера, що відповідає індивідуальним початкового тексту (ідентичні вихідні тексти мають одне значення хеш-коду). Ці прості засоби використовуються і поєднуються для створення інфраструктури відкритого ключа (PKI).
проверяемое посвідчення
Посвідчення всередині системи PKI управляються з використанням цифрових сертифікатів, які не сильно відрізняються від виданих державою посвідчень особи, які більшість людей переносять через міжнародні кордони, - паспортів. Стандарт паспортів в світі цифрових сертифікатів - це формат X.509, який широко використовується для підписування і шифрування в таких технологіях як S / MIME, IPsec, SSH, а також в безпеці бездротових мереж, віртуальних приватних мережах (VPN) і навіть в безпечних повідомленнях сервера (таких як веб-вузли SSL).
Сертифікати будуються на основі асиметричної криптографії та хеш-кодів. Для створення сертифіката запитувач (той, кому потрібен ключ, підписаний вищим центром сертифікації), створює секретний ключ. Ключ тримається замкненим, щоб його справжність не піддавалася сумніву. Разом з секретним ключем створюється відповідний відкритий ключ. Як і передбачає його ім'я, відкрита частина пари не секретна і вільно поширюється, хоча все ж таким способом, який гарантує її справжність.
Ця пара ключів робить можливою дві основні операції. По-перше, будь-хто може використовувати відкритий ключ для шифрування чого-небудь, що може розшифрувати тільки секретний ключ; по-друге, відкритий ключ можна використовувати для розшифровки зашифрованого секретним ключем. Це має значення при перевірці підпису, яку міг створити тільки секретний ключ.
Запит до центру сертифікації включає такі подробиці, як то,-якій особі або комп'ютера призначається ключ, тип і надійність алгоритму, а також відкриту частину пари ключів. Центр сертифікації (CA) отримує і перевіряє інформацію в запиті, після чого, використовуючи алгоритм хешування, створює унікальний ідентифікатор, відповідний інформації.
Використовуючи свій закритий ключ, центр сертифікації шифрує хеш-код інформації і збирає його в стандартний формат (такий як X.509), створюючи сертифікат, відповідний початкового запиту. Сертифікат X.509 буде містити список заявок, включаючи посвідчення сертифікату (суб'єкт), період дійсності, відкритий ключ і операції, для яких може бути використаний сертифікат. Після цього сертифікат повертається запитувачу; це маркер, який по суті заявляє: «Я, центр сертифікації (CA), ручаюсь за цей відкритий ключ і секретну частину, відповідну йому, для всіх описаних тут способів використання».
У кореневих центрів сертифікації (що знаходяться на найвищому рівні ланцюга довіри) сертифікати самоподпісанного. Більшість прийнятних кореневих центрів сертифікації поставляються вбудованими в базову операційну систему або додаток, але можуть бути оновлені або змінені через пакети або корпоративну настройку. Між кореневих центром сертифікації і кінцевим вузлом дерева (який зазвичай описує окрему особистість чи систему) можуть перебувати один або кілька кореневих центрів сертифікації.
Ланцюг складається з усіх вузлів і всіх попередніх сертифікатів, впроваджених в них, підписаних центром сертифікації на цьому рівні. Стороння особа, що намагається перевірити сертифікат, може звірити локально обчислюється хеш-код з дешифрувати з самого сертифіката, використовуючи супроводжуючий загальний ключ для даного конкретного центру сертифікації або особистості. Таким чином і створюється повністю перевірена ланцюг від кореня до кінцевого вузла дерева - припускаючи, само собою, що корінь користується довірою.
Оновлення статусу сертифіката
У кожного доброго центру сертифікації є способи поширення списку сертифікатів, яким більше не слід довіряти. Цей список відкликання сертифікатів (CRL) описує, які випущені елементи центр сертифікації прямо зробив недійсними. Що зручно, місце розташування списку відкликання сертифікатів зазвичай є властивістю сертифіката центру сертифікації.
Багато додатків витрачають набагато більше часу на завантаження сертифіката, якщо вони не можуть перевірити ланцюг або список відкликання сертифікатів для кожного вузла в ланцюзі. Залежно від того, що захищав сертифікат, користувач може побажати або не захотів довіряти йому. Регулярно оновлювана, широко доступна точка розповсюдження списку відкликаних сертифікатів абсолютно необхідна для кожного центру сертифікації, а особливо для загальнодоступних коренів.
Коріння є підставою ланцюга сертифікатів, а на з'єднанні в ланцюзі засновані всі ієрархії сертифікатів. Більшість клієнтських систем і додатків припускають, що сертифікат кінцевого вузла дерева допустимо, тільки якщо від нього веде ланцюг до довіреній корені. Це може бути корпоративний центру сертифікації, що знаходиться у володінні і під управлінням даної конкретної компанії, або загальнодоступний кореневої центр сертифікації (такий як VeriSign).
Нарешті, в кожну хорошу криптографічний систему входить концепція управління життєвим циклом. Чим комп'ютери швидше, тим менш стійкі алгоритми. Будь хорошою криптосистеме необхідна здатність оновлювати себе і переходити на нові алгоритми і розміри ключів з плином часу. Центри сертифікації слід оновлювати відповідним чином, коли визначаються криптографічні нестійкості і певні функції вводяться в експлуатацію або виводяться з неї.
Реалізація S / MIME
Ми припустимо, що вже існує необхідна інфраструктура, яка припускає операції, які ми опишемо. У нашому випадку ми використовуємо інтегрований з Active Directory корпоративний сервер сертифікації.
отримання сертифікатів
Перше завдання - це отримати відповідні сертифікати. Щоб зробити це, відкрийте консоль управління MMC диспетчера сертифікатів (certmgr.msc), клацніть правою кнопкою миші папку Personal ( «Особисті»), виберіть All Tasks ( «Усі завдання») у спливаючому списку і виберіть Request New ( «Просити новий») з списку.
В результаті запуститься майстер установки сертифікатів, як показано на рис. 1. За замовчуванням будуть показані кілька призначених для компаній варіантів, важливий з них User certificate ( «Сертифікат користувача»). Пізніше він буде використаний, щоб зробити можливими процеси підписування і шифрування. Сертифікат повинен бути придатний для наступного.
Мал. 1 Запит сертифіката
- Цифрових підписів (створення повідомлень з печаткою справжності від їх творця)
- Криптографічного захисту ключа (захисту одного ключа іншим для таких технологій, як шифрующая файлова система)
- Безпечного обміну електронною поштою (зашифрованих повідомлень, які можуть бути прочитані тільки їх передбачуваним одержувачем, що володіє відповідним секретним ключем)
Для відправки підписаної S / MIME електронної пошти властивості криптографічного захисту ключа не потрібно. Але для відправки або отримання зашифрованою пошти це властивість необхідно, тоді як властивість підпису - немає. За замовчуванням, шаблони в службі сертифікатів Windows® включають ці три властивості. Якщо користувачеві не дозволено виконувати нові сертифікати, вони не будуть показуватися при запуску майстра. Якщо корпоративний центр сертифікації недоступний, користувачеві буде представлена «помилка установки», яка вказує, що з доменом або з центром сертифікації неможливо зв'язатися. Для цілей цього керівництва ми припустимо, що один сертифікат допускає і підпис, і криптографічний захист.
обмін сертифікатами
Найпростішим способом почати обмін зашифрованими повідомленнями електронної пошти між двома користувачами є відправка один одному підписаних повідомлень. Після складання повідомлення користувач натискає кнопку «Підписати». (Часом кнопка прихована за замовчуванням в Outlook, поки її не використали хоч раз. Її можна знайти, вибравши «Параметри для нових повідомлень», потім натиснувши кнопку «Параметри безпеки» і встановивши прапорець «Додати цифровий підпис до цього повідомлення» в діалоговому вікні властивостей безпеки.) Кнопка підписування (маленький жовтий конверт з червоною стрічкою на ньому з написом «Підписати») додає цифровий підпис до повідомлення, щоб встановити справжність його джерела.
Мал. 2 При обміні сертифікатами не експортує секретний ключ
Кожен одержувач потім вручну створює запис контакту в Outlook і додає сертифікат до запису відправника. Після того, як двоє користувачів обмінялися сертифікатами, у них буде можливість обмінятися один з одним зашифрованими повідомленнями електронної пошти.
Усунення несправностей
Часом у одержувача виникають складнощі у відкритті зашифрованого повідомлення. Найбільш ймовірними джерелами проблем тут є недовірених кореневі центри сертифікації, проміжні центри сертифікації, які неможливо перевірити, і недоступні списки відкликаних сертифікатів.
Недовірених кореневої центр сертифікації зазвичай з'являється в Outlook як повідомлення про помилку, пов'язану з підписом: «Є труднощі, пов'язані з підпису. Для отримання додаткових відомостей натисніть кнопку підпису ». Для вирішення проблеми відкрийте сертифікат зсередини Outlook і натисніть кнопку «Про центр сертифікації. »Зі спливаючого діалогу. Погляньте на повідомлення на вкладці «Загальні» або в діалозі властивостей сертифіката. Якщо воно вказує, що кореневий сертифікат центру сертифікації не користується довірою, і його потрібно встановити, перейдіть на вкладку відомостей. Натисніть кнопку «Копіювати в файл. »І виконайте вказівки майстра, приймаючи всі параметри за замовчуванням і надаючи ім'я та папку файлу за запитом.
Друга проблема зазначена вище, неможливість перевірити проміжні центри сертифікації, зазвичай виникає в двох випадках: коли клієнт, який намагається перевірити сертифікат, не може отримати доступ до місця розташування інформації про центр сертифікації (AIA), визначеного в сертифікаті, або у клієнта є версія сертифікату проміжного центру сертифікації, яка не збігається з тим, що випускає центр сертифікації (клієнт часто відстає на версію або дві). Ці умови видаються дуже схожими в інтерфейсі користувача Outlook. Ми бачили це тільки в дуже спеціальних обставин, коли термін дії сертифіката проміжного центру сертифікації в ланцюзі закінчувався, і сертифікат видавався заново, перш ніж минав термін дії випущених центром сертифікації підлеглих сертифікатів.
По суті, ця проблема виникає, коли в ланцюзі є прогалини. Деякі батьківські сертифікати можуть бути не дуже деталізованими або НЕ впровадженими в крайовий вузол дерева належним чином, що ще більше ускладнює ситуацію.
Мал. 3 Заповнення прогалин в ланцюзі сертифікатів
Після отримання експортованої ланцюга сертифікатів одержувачу знадобиться відкрити і імпортувати ланцюг приблизно так само, як ми раніше імпортували корінь. Єдина різниця полягає в тому, що обраної папкою зберігання повинні бути «Проміжні центри сертифікації». Якщо повідомлення відкривається, і сертифікат показаний як допустимий в Outlook, то все працює вірно.
Що стосується третьої проблеми, недоступності списку відкликання сертифікатів, то виправлення відносно просто. Початковий відповідь від Outlook буде виглядати вельми схожим на попередню проблему. Однак помилка буде показана, навіть якщо кореневі або проміжні підписують центри сертифікації користуються довірою. Для кожного рівня ланцюга сертифікатів вище кінцевого відкрийте властивості сертифіката, потім вкладку відомостей і погляньте на поле, іменоване «Точки розповсюдження списку відкликаних (CRL)».
поширення сертифікатів
Поширення - це проста частина. По суті, підписане повідомлення передається серверу електронної пошти, який потім відсилає його з одного місця в інше перевіреним способом - через SMTP. Єдина бачена нами проблема при передачі підписаної або зашифрованою пошти полягає в тому, що деякі поштові системи відкидають або розбивають підписані або зашифровані повідомлення, що проходять через них. Спосіб виправлення полягає в роботі з керівником ІТ-системи для отримання допустимих типів повідомлень. Само собою, можливо, доведеться змиритися з фактом, що деякі типи повідомлень блокуються. У одержувача можуть бути вагомі причини не допускати зашифровані повідомлення в певній робочому середовищі.
Шифрування відповідей.
Для створення зашифрованого відповіді (припускаючи, що вищезгаданий процес початкового завантаження вже завершено) відправнику необхідно лише створити повідомлення і потім натиснути кнопку «Зашифрувати» (маленький жовтий конверт з синім замком на ньому з написом «Зашифрувати») у вікні складання повідомлень. Якщо ця кнопка недоступна, виконайте всі дії по відправці підписаного повідомлення, крім останнього, замість якого встановіть прапорець "Шифрувати вміст повідомлення та вкладення».
Підпис S / MIME не потрібно для відправки одержувачу зашифрованого повідомлення, але те й інше відмінно працюють разом, оскільки підпис дозволяє читачеві перевірити сервер (функція шифрування не засвідчує відправника). Процес шифрування спробує зашифрувати повідомлення за допомогою відомих відкритих ключів всіх одержувачів. Якщо система не може знайти сертифікати для деяких передбачуваних одержувачів, вони будуть позначені у спливаючому діалозі, який пропонує відправити повідомлення незашифрованим, як показує рис. 4.
Мал. 4 Можна вирішити відправити незашифроване повідомлення при наявності проблеми з сертифікатом
За замовчуванням підписування і шифрування повинні працювати з іншими порівняно налаштованими клієнтськими системами, але часом обмін підписаними або зашифрованими повідомленнями між декількома версіями може привести до проблем, якщо алгоритм хешування або шифрування не підтримуються на попередньому рівні. Ми зіткнулися з такою проблемою при відправці підписаних повідомлень електронної пошти (використовуючи SHA-512 як алгоритм хешування) користувачеві, що використовує Windows XP з пакетом оновлень 2. Оскільки отримує система не підтримувала хешування, користувачеві не вдавалося перевірити підпис або прочитати повідомлення. Однак якщо параметри Outlook за замовчуванням не змінювалися, користувачі навряд чи зустрінуть багато проблем на цьому етапі.
Після отримання повідомлення передбачуваний одержувач повинен бути здатний відкрити його, якщо доступний відкритий ключ, пов'язаний з загальнодоступним сертифікатом. Крім того, від користувача може знадобитися надання додаткового маркера, що підтверджує володіння секретним ключем, в залежності від того, як він був розгорнутий. Інші користувачі, які виконали подібну процедуру ініціалізації, можуть взяти участь у подібній підписаної і зашифрованою листуванні з одержувачем. Якщо користувач змінив свій секретний ключ (скажімо, через втрату комп'ютера), йому потрібно повторно запросити сертифікати і заново поширити підписане повідомлення або файл сертифікату між тими, з ким він хоче обмінюватися зашифрованими повідомленнями.
Висновок.
Змусити підписану і зашифровану S / MIME працювати між двома користувачами в двох різних каталогах або організаціях зазвичай не сильно складніше, ніж виконати описане вище. Підпис дуже зручна при правильному використанні, оскільки засвідчує справжність повідомлення. Зашифровані повідомлення надають додатковий рівень секретності при передачі даних для конфіденційних повідомлень. Разом вони забезпечують і підтвердження автентичності відправника, і секретність даних. А описаний тут процес дозволяє більшості користувачів без праці скористатися цими можливостями.