2. Режим зчеплення шифрованих блоків

Технологія, вільна від недоліків режиму ЕСВ, повинна в разі повторення в повідомленні блоку відкритого тексту, який вже зустрічався раніше, генерувати блок шифрованого тексту, відмінний від згенерованого раніше. Найпростіше добитися цього за допомогою режиму зчеплення шифрованих блоків (СВС). У цьому режимі (див. рис. 5.2) вхідне значення алгоритму шифрування задається рівним XOR-різниці поточного блоку відкритого тексту і отриманого на попередньому кроці блоку шифрованого тексту. Шифрування будь-якого блоку виконується за одним і тим же ключем. У результаті в процесі шифрування всі блоки відкритого тексту виявляються пов'язаними, а вхідні дані, що надходять на вхід функції шифрування, вже не жорстко пов'язані з блоками відкритого тексту. Тому повторювані 64-бітові послідовності в зашифрованому тексті не проявляються.

При дешифруванні текст теж проходить через алгоритм дешифрування поблочно. При цьому відповідний блок відкритого тексту виходить як XOR-різниця вихідного блоку алгоритму дешифрування і попереднього блоку шифрованого тексту. Щоб зрозуміти, як це відбувається, запишемо процес шифрування у вигляді формули

Тоді

Щоб отримати перший блок шифрованого тексту, розглядається XOR-різниця деякого ініціалізаційного вектора (IV) і першого блоку відкритого тексту. При дешифруванні для відновлення першого блоку відкритого тексту необхідно буде теж виконати операцію XOR по відношенню до того ж вектору IV і першому блоку на виході алгоритму дешифрування.

Рис. 5.2. Режим зчеплення шифрованих блоків (СВС)

Значення IV має бути відомо і відправнику, і одержувачу повідомлення. Для забезпечення максимальної безпеки значення IV має бути захищене точно так само, як і ключ. Можна, наприклад, відправити значення IV, зашифрувавши його в режимі ЕСВ. Однією з причин, по яких необхідно захищати IV, є наступна: якщо противник має можливість обдурити адресата повідомлення, надавши підроблений IV, то супротивник одержує можливість інвертувати обрані біти в першому блоці відкритого тексту. Щоб переконатися в цьому, розглянемо наступні рівняння:

Позначивший i-й біт 64-бітового значення X через Х[£], отримаємо

Тому, використовуючи властивості операції XOR, можемо зробити висновок, що

де штрих означає додаток біта. Як бачите, якщо супротивник має можливість керованим чином міняти біти значення IV, він зможе поміняти і відповідні значення Р1.

Описи інших порушень, що базуються на знанні IV, наведені в [VOYD83].

На закінчення зазначимо, що завдяки механізму зчеплення блоків СВС цей режим виявляється підходящим для шифрування повідомлень, довжина яких перевищує 64 біта.

Крім забезпечення конфіденційності, режим СВС можна використовувати для аутентифікації.

3. Режим шифрованого зворотного зв'язку

Схема DES являє собою блоковий шифр із розміром блоку 64 біта. Але DES можна перетворити і в потоковий шифр, використовуючи або режим шифрованого зворотного зв'язку (СFВ), або режим зворотного зв'язку по виходу (OFB). Використання потокового шифру позбавляє від необхідності доповнювати повідомлення до цілого числа блоків. Крім того, з потоковим шифром можна працювати в режимі реального часу. Наприклад, при передачі потоку символів за допомогою посимвольного потокового шифру кожен символ можна шифрувати і відразу ж передавати адресату, не чекаючи закінчення шифрування решті частини повідомлення.

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

На рис. 5.3 показана схема шифрування в режимі CFB. Передбачається, що одиницею передачі даних є у бітів (зазвичай у = 8). Як і в режимі СВС, відбувається зчеплення елементів відкритого тексту, тому шифрований текст, який відповідає будь-якому елементу відкритого тексту, залежатиме від усіх попередніх елементів відкритого тексту.

Спочатку розглянемо шифрування. На вході функції шифрування розміщується 64-бітовий регістр зсуву, в якому спочатку розміщується деяке значення ініціалізаційного вектора (IV). Крайні зліва (головні) у бітів цього значення зв'язуються операцією XOR з першою порцією відкритого тексту Р₁, в результаті чого виходить перша порція шифрованого тексту С₁, який подається на лінію передачі даних. Вміст регістра зсуву зміщується вліво на у бітів, а в крайні справа (найменш значущі) у бітів поміщається значення С₁. Потім весь процес повторюється до тих пір, поки не будуть зашифровані всі елементи відкритого тексту.

Для дешифрування використовується та ж схема, але для отримання чергової порції відкритого тексту за допомогою операції XOR зв'язуються отримана по зв'язку порція шифрованого тексту і одержувані на виході функції шифрування дані. Зверніть увагу, що в даному випадку використовується функція шифрування, а не дешифрування. Пояснити це просто. Позначимо крайні зліва j бітів значення X через S_j(Х).

Тоді

і тому

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

Рис. 5. 3. Режим j-бітового шифрованого зворотнього зв'язку (CFB)

Режим зворотного зв'язку по виходу

Режим зворотного зв'язку по виходу (ОFВ), як видно з рис. 5.4, багато в чому подібний режиму СFВ. В режимі ОFВ в регістр зсуву подається значення, одержуване на виході функції шифрування, а в режимі СFВ в цей регістр подається порція шифрованого тексту.

Режим ОFВ володіє тією перевагою, що вплив можливих спотворень бітів при передачі даних не поширюється на наступні порції даних. Наприклад, якщо спотворені біти з'явилися при передачі С₁ це вплине тільки на відновлене з С₁ значення Р₁ а всі наступні порції відкритого тексту через цю помилку передачі даних пошкоджені не будуть.

Рис. 5. 4. Режим j-бітового зворотнього зв'язку по виходу(ОFB)

У випадку CFB значення С₁ використовується в якості вхідного для регістра зсуву, внаслідок чого спотворення С₁ виллється в додаткові спотворення для всього потоку прийнятих даних. Недоліком режиму OFB, з іншого боку, є те, що він забезпечує меншу, ніж CFB, надійність відносно порушень типу модифікації потоку даних. Наприклад, зміна одного біта шифрованого тексту відображається у зміні відповідного біта відновленого відкритого тексту. Це дає можливість здійснення контрольованих змін в одержуваному адресатом відкритому тексті. Практично, щоб програма корекції помилок не помітила підміни, противник повинен внести необхідні йому зміни як в дані, що представляють собою порцію шифрованого тексту, так і в дані, що представляють контрольну суму для цієї порції тексту. Детальніше ці питання висвітлені в [VOYD83].

Розподіл ключів

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

1. Ключ може бути вибраний стороною А і фізично доставлений стороні В.

2. Ключ може вибрати третя сторона і фізично доставити його учасникам А і В.

3. Якщо учасники обміну А і В вже використовують певний загальний ключ, одна зі сторін може передати новий ключ другій стороні зашифрованим, використовуючи старий ключ.

4. Якщо обидві зі сторін А і В мають криптографічно захищені канали зв'язку з третьою стороною С, то остання може доставити ключ учасникам А і В за цим захищених каналах.

Рис. 5.5. Пристрій доповнення потоку даних незначущою інформацією

Варіанти 1 і 2 припускають передачу ключа з рук в руки. При канальному шифруванні ця вимога може виявитися цілком розумним, оскільки будь-який пристрій канального шифрування передбачає обмін даними тільки з відповідним пристроєм на іншому кінці каналу. Але у випадку наскрізного шифрування фізична доставка ключа практично неприйнятна. У будь-якій розподіленій системі кожен ведучий вузол або термінал може брати участь в обміні даними з багатьма іншими провідними вузлами і терміналами. Тому кожному такому пристрою потрібно безліч ключів, які доведеться поставляти динамічно. Проблема виявляється досить важкою для рішення, особливо в разі великих глобально розподілених систем.

Масштаб проблеми залежить від числа контактуючих пар, які доводиться обслуговувати. Якщо наскрізне шифрування здійснюється на мережевому рівні або на рівні IP, то буде потрібно по одному ключу для кожної пари ведучих вузлів в мережі, які обмінюються даними. Тому якщо є N провідних вузлів, число необхідних ключів дорівнюватиме [N (N - 1)] / 2. Якщо шифрування здійснюється на рівні додатку, то свій ключ буде потрібно для кожної пари користувачів або процесів, що виходять на зв'язок. При цьому мережа може мати сотні провідних вузлів і тисячі користувачів і процесів. На рис. 5.6 для випадку наскрізного шифрування показана залежність складності завдання розподілу ключів від числа пар, що беруть участь в обміні даними. Наприклад, в мережі, що нараховує 1000 вузлів, де шифрування здійснюється на рівні вузла, швидше за все, доведеться розподіляти близько півмільйона ключів. А якщо в такій мережі підтримується близько 10 000 додатків, то при шифруванні на рівні додатків може знадобитися розподілити близько 50 мільйонів ключів.

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

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

Рис. 5.6. Число ключів, необхідне для підтримки будь-яких з'єднань між заданим числом кінцевих точок

Використання центру розподілу ключів передбачає організацію деякої ієрархії ключів. У мінімальній конфігурації така ієрархія включає два рівня (рис. 5.7). Зв'язок між кінцевими системами шифрується з використанням тимчасового ключа, часто званого сеансовим ключем (session key). Як правило, сеансовий ключ служить тільки для конкретного логічного з'єднання, наприклад віртуального каналу або для транспортування даних, після чого цей ключ більше не застосовується. Сеансовий ключ отримують від центру розподілу ключів по тим же засобам доставки даних у мережі, які служать для організації зв'язку між кінцевими користувачами. Відповідно, сеансові ключі передаються у зашифрованому вигляді, а для шифрування використовується головний ключ (master key), загальний для центру розподілу ключів і даної кінцевої системи або конкретного користувача.

Для кожної кінцевої системи або кінцевого користувача створюється унікальний головний ключ, який застосовується спільно з центром розподілу ключів. Звичайно, ці головні ключі теж повинні бути якимось чином розподілені. Однак ця проблема по своїй складності значно простіше. Як уже згадувалося, для N об'єктів, попарно обмінюються даними, потрібно [N (N -1)] / 2 сеансових ключів. А головних ключів потрібно всього N, по одному на кожен об'єкт. Тому головні ключі можуть бути розподілені деяким некриптографічним чином, наприклад фізичної доставкою адресату.

Рис. 5.7. Використання ієрархії ключів

Сценарій розподілу ключів

Розподіл ключів можна реалізувати різними способами. Типовий сценарій показаний на рис. 5.8, за основу якого взято відповідний малюнок з [РОРЕ79]. Цей сценарій передбачає, що кожен користувач має унікальний головний ключ, використовуваний спільно з центром розподілу ключів (ЦРК).

Припустимо, що користувач А має намір створити логічне з'єднання з користувачем В і для захисту даних, які передбачається передати під час цього з'єднання, потрібно одноразовий сеансовий ключ. При цьому користувач А має секретний ключ К_а, відомий тільки йому і ЦРК, і точно так само В використовує спільний з ЦРК головний ключ К_b. Система обміну інформацією виглядає наступним чином.

1. Ініціатор А посилає запит до ЦРК на отримання сеансового ключа для захисту логічного з'єднання з В. Послане при цьому повідомлення повинно включати інформацію, що дозволяє однозначно визначити А і В, а також деякий ідентифікатор N1, унікальний для даного запиту, зазвичай званий оказією (nonce) . Таким ідентифікатором може бути поточний час, деякий лічильник або випадкове число - як мінімум, цей ідентифікатор повинен бути унікальним для кожного запиту. Крім того, щоб запобігти можливості фальсифікації повідомлення противником, має бути непросто вгадати цей ідентифікатор для противника. Тому гарним вибором для оказії можна вважати випадкове число.

2. ЦРК відповідає на запит повідомленням, шифрованим з використанням ключа К_a. Єдиним користувачем, хто може отримати і прочитати це повідомлення, є А і тому А може бути впевненим, що це повідомлення прийшло від ЦРК. Повідомлення включає два елементи, призначених для А:

• одноразовий сеансовий ключ К_s, який буде використовуватися в сеансі зв'язку;

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

3. Таким чином, А може упевнитися, що його початковий запит не змінено на шляху до ЦРК, а оказія не дозволить переплутати відповідь на даний запит з відповіддю на який-небудь з попередніх запитів.

4. Крім того, повідомлення включає і два елементи, призначені для В:

• одноразовий сеансовий ключ K_s, який буде використовуватися в сеансі зв'язку;

• ідентифікатор ID_A користувача А (наприклад, його мережеву адресу).

5. Обидва елементи шифруються за допомогою ключа К_b (головного ключа, застосовуваного спільно ЦРК і В), і передбачається, що вони повинні бути згодом відправлені В, щоб встановити з'єднання та ідентифікувати А.

6. Сторона А зберігає сеансовий ключ для майбутнього сеансу зв'язку і пересилає стороні В інформацію, отриману від ЦРК і призначену для В (а саме інформацію Е_Kb [К_s || ID_А]). Оскільки ця інформація шифруватися з використанням К_b, вона виявляється захищеною. Тепер одержувач В знає сеансовий ключ (К_s) і знає, що отримана інформація прийшла від ЦРК (оскільки ця інформація виявляється зашифрованою з використанням ключа К_b).

Рис. 5.8. Сценарій розподілу ключів

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

1. Використовуючи щойно отриманий сеансовий ключ К_s для шифрування, сторона В посилає стороні А нову оказію N₂.

2. За допомогою того ж ключа К, сторона А у відповідь повертає f (N₂), де f є функцією, що виконує деякий перетворення N₂ (наприклад, додавання одиниці).

Ці дії покликані переконати адресата У в тому, що спочатку отримане ним повідомлення (п. 3), не було відтворене.

Зверніть увагу на те, що сам процес передачі ключа фактично виконується в пп. 1-3, а пп. 4 і 5, так само, як частково й п. 3, покликані забезпечити функцію аутентифікації.

Управління ієрархією ключів

Зовсім необов'язково покладати функцію розподілу ключів на один ЦРК. Насправді для великих мереж це взагалі непрактично. Вигідніше визначити деяку ієрархію центрів розподілу ключів. Наприклад, можна створити локальні ЦРК, відповідальні за малі домени всій мережі, скажімо, окремі локальні мережі або мережі, розміщені в одній будівлі. Тоді при зв'язку між об'єктами всередині одного локального домену за розподіл ключів відповідатиме локальний ЦРК. Якщо ж загальний ключ буде потрібно для зв'язку двох об'єктів з різних доменів, то відповідні локальні ЦРК можуть використовувати для переговорів ЦРК глобального рівня. У цьому випадку будь-який з трьох залучених в переговори ЦРК може генерувати відповідний ключ. Така ієрархія може складатися і з трьох або навіть більшого числа рівнів - залежно від кількості користувачів та географічної протяжності мережі.

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

Тривалість використання сеансового ключа

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

Для протоколів з встановленням логічних з'єднань очевидним варіантом є застосування одного ключа протягом сеансу зв'язку тільки одного відкритого з'єднання і використання нового ключа для кожного нового сеансу зв'язку. Якщо логічне з'єднання не переривається занадто довго, розсудливо періодично міняти ключ сеансу - наприклад, після обробки певного числа протокольних одиниць обміну (PDU - Protocol Data Unit).

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

Прозора схема управління ключами

Підхід, загальна схема якого показана на рис. 5.7, має багато варіантів, один з яких описується в даному розділі. Варіант, про який піде мова (див. рис. 5.9) застосуємо при наскрізному шифруванні на мережевому або транспортному рівні, яке має бути непомітним для кінцевих користувачів. Даний підхід передбачає, що для зв'язку обраний деякий протокол наскрізної передачі даних з встановленням логічних з'єднань, наприклад Х.25 або TCP. Вартим уваги елементом такого підходу є комунікаційний процесор (наприклад такий, який показаний на рис. 5.3), що реалізує функцію наскрізного шифрування і отримує сеансові ключі від провідного вузла або терміналу.

На рис. 5.9 відображені дії, які виконуються при здійсненні з'єднання. Коли один ведучий вузол готовий з'єднатися з іншим провідним вузлом, він передає вимагає з'єднання пакет (крок 1). Комунікаційний процесор (КП) зберігає цей пакет і звертається до ЦРК за дозволом встановити з'єднання (крок 2). Зв'язок між КП і ЦРК шифрується з використанням головного ключа, відомого тільки КП і ЦРК. Якщо ЦРК дозволяє з'єднання, він генерує сеансовий ключ і доставляє його двом відповідним комунікаційним процесорам, використовуючи при шифруванні унікальні постійні ключі, свої для кожного з цих двох комунікаційних процесорів (крок 3). Комунікаційний процесор, який видав запит, тепер може звільнити вимагає з'єднання пакет і встановлює з'єднання між двома кінцевими системами (крок 4). Всі призначені для користувача дані, що пересилаються між двома кінцевими системами, шифруються їх відповідними комунікаційними процесорами з використанням отриманого одноразового сеансового ключа.

Рис. 5.9. Автоматичний розподіл ключів для протоколу з встановленням логічних з'єднань

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

Децентралізоване управління ключами

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

При децентралізації потрібно, щоб кожна кінцева система мала можливість обмінюватися даними деяким захищеним чином з усіма іншими потенційно досяжними кінцевими системами з метою розподілу сеансових ключів. При цьому в мережі n кінцевими системами може знадобитися до [n (n-1)] / 2 головних ключів.

Сеансовий ключ може бути визначений в результаті наступної послідовності дій (рис. 5.10).

1. Ініціатор А посилає запит учаснику обміну даними B на отримання сеансового ключа, що містить також оказію N₁.

2. Респондент В відповідає повідомленням, зашифрованим з використанням загального головного ключа. Ця відповідь містить сеансовий ключ, обраний стороною В, ідентифікатор В, значення f (N₁) та іншу оказію N₂.

3. Використовуючи отриманий сеансовий ключ, сторона А повертає стороні В значення f (N₂).

Рис. 5.10. Децентралізований розподіл ключів

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

Управління використанням ключів

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

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

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

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

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

Зважаючи на це бажано, щоб в системі були засоби управління, обмежуються використання ключів шифрування залежно від характеристик, що пов'язуються з такими ключами. Одним з найпростіших підходів є зв'язування з кожним ключем деякої ознаки ([JONE82], див також [DAVI89]). Запропонований підхід застосовується в разі DES, де для ознаки використовуються незадіяні 8 бітів 64-бітового ключа DES. Іншими словами, 8 не використовуваних для ключа бітів, зазвичай резервуються для контролю парності, задають значення ознаки ключа. Ці біти мають наступну інтерпретацію:

• один біт вказує, яким є ключ - сеансовим або головним;

• один біт вказує, чи може ключ служити для шифрування;

• один біт вказує, чи може ключ застосовуватися для дешифрування;

• інші біти зарезервовані для використання в майбутньому.

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

Більш гнучка схема, звичайно звана схемою на основі керуючого вектора, описана в [MATY91a] і [MATY91b]. У цій схемі кожен сеансовий ключ асоціюється з керуючим вектором, що складається з ряду полів, що описують можливості застосування та обмеження для даного сеансового ключа. Довжина керуючого вектора може змінюватися.

Керуючий вектор криптографічними засобами зв'язується з ключем під час створення ключа в ЦРК. Процеси зв'язування та поділу показані на рис. 5.11. Спочатку керуючий вектор проходить через функцію хешування, в результаті чого виходить значення, довжина якого дорівнює довжині ключа шифрування. Функції хешування докладно описані в главі 8. По суті, функція хешування відображає значення з деякої більшої області в деяку меншу область, забезпечуючи при цьому однорідний в деякому сенсі розкид значень. Наприклад, якщо числа з діапазону від 1 до 100 скорочуються в діапазон від 1 до 10, то в кожне результуюче значення повинне відображатися приблизно 10% вихідних значень.

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

Значення хешування = Н = h(CV),

Значення ключа =

Шифрований текст =

де К_m означає головний ключ, а К_s — сеансовий ключ.

Рис. 5.11. Шифрування й дешифрування керуючого вектора

Сеансовий ключ відновлюється у відкритий вигляд за допомогою зворотної операції:

Поряд з сеансовим ключем користувачеві від ЦРК доставляється керуючий вектор у відкритій формі. Сеансовий ключ можна відновити лише за наявності і головного ключа, загального для даного користувача і ЦРК, і керуючого вектора. Таким чином підтримується зв'язок між сеансовий ключем і відповідним йому керуючим вектором.

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