Розроблення та синтез VHDL-моделей елементів пристроїв захисту інформації

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЛЬВІВСЬКА ПОЛІТЕХНІКА»

КУРСОВА РОБОТА з навчальної дисципліни: «Комп`ютерні методи високорівневого проектування пристроїв захисту «на тема:

«Розроблення та синтез VHDL-моделей елементів пристроїв захисту інформації»

Львів — 2012

Зміст Завдання Аналітичний розділ з роз’ясненням та аналізом основних принципів побудови та реалізації пристрою в ПЛІС Розділ з описом заданих алгоритмів шифрування та режимів обробки даних Розділ з описом розробки архітектури пристрою та його структурної схеми на рівні між регістрових передач Розділ з описом розробки VHDL — моделей компонент пристрою та VHDL — пристрою в цілому Розділ з описом розробки системи тестування для виконання тестування пристрою та з результатами симуляції пристрою у формі часових діаграм, результати синтезу пристрою

Cинтез розробленої VHDL — моделі пристрою в ПЛІС Висновки Список використаної літератури тестування пристрій захист інформація Завдання Відповідно до НЗК (номера залікової книжки) визначити варіант завдання наступним чином: (аb тоd 25 + 1), аb — дві останні цифри НЗК. Варіант завдання подано в таблиці нижче.

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

Розробити систему тестування та з її допомогою виконати функціональну симуляцію розробленої VHDL — моделі пристрою.

Для магістрів — виконати синтез розробленої VHDL — моделі пристрою в ПЛІС за власним вибором, а також виконати часову симуляцію розробленої VHDL — моделі пристрою з допомогою розробленої системи тестування.

Аналітичний розділ з роз’ясненням та аналізом основних принципів побудови та реалізації пристрою в ПЛІС Етапи проектування програмних моделей процесорів на рівні міжрегістрових передач та їх реалізації у програмовних логічних інтегральних схемах (ПЛІС) зображено на рис. 1.

Рис. 1. Етапи проектування програмних моделей процесорів на рівні міжрегістрових передач та їх реалізації у програмовних логічних інтегральних схемах.

Структура процесора визначається під час його функціональної декомпозиції: кожен з модулів процесора повинен бути функціонально незалежним. В загальному критеріями якості розбиття схеми на модулі є функціональна незалежність модулів та кількість міжмодульних з'єднань (чим менше — тим краще).

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

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

Після функціональної симуляції проводиться логічний синтез програмної моделі процесора у ПЛІС. На цьому етапі код з мови опису апаратних засобів транслюється у код, який використовується як вхідний при програмуванні кристалу. На етапі логічного синтезу процесора у ПЛІС отримуються його характеристики — частота роботи та розмір на кристалі (затрати обладнання). Таким чином розробник може визначити, чи задовольняє розробка вимоги технічного завдання, чи ні. Дуже важливим є те, що засоби логічного синтезу ПЛІС генерують результуючий файл мовою опису апаратних засобів, який відображає фізичну модель синтезованого процесора. Ця модель є описом процесора на рівні логічних комірок (примітивів) ПЛІС, яку використовують, і відображає всі часові затримки при проходженні інформації у кристалі. Розробник, використовуючи розроблену систему тестування, може перевірити, чи є працездатною фізична модель процесора. Цей процес називається часовою симуляцією синтезованого процесора. Помилки, що виникають на етапі часової симуляції, виявляються та усуваються значно важче ніж ті, що виникають на етапі функціональної симуляції. Такі помилки свідчать або про неякісно розроблену програмну модель процесора, або про невдале використання особливостей примітивів ПЛІС (наприклад, наявність так званих хибних шляхів, завищення частоти синхроімпульсів тощо). Якщо синтезована модель успішно витримала часову симуляцію, то наступним кроком є програмування ПЛІС. Результат перевірки пристрою, реалізованого у ПЛІС, дає змогу зробити висновок про відповідність розробленого процесора технічному завданню. Якщо процесор відповідає технічному завданню, то його передають на етап системного тестування. Якщо системний тест не виявив помилок, то процесор готовий до використання. Помилки, які можуть виникнути на цьому етапі, виявити та усунути найважче. Вони можуть бути спричинені відсутністю сигналу скиду у певних елементах ПМП чи порушенням синхронізації. Інколи це трапляється через порушення температурного режиму роботи кристалу, завищення частоти синхроімпульсів чи від відхилення взірця кристалу від його стандартних технічних параметрів.

Типовий склад конструкторської документації проекту програмної моделі процесора є наступним:

функціональна модель процесора, написана мовою опису апаратних засобів, VHDL або Verilog (VHDL — модель, Verilog — модель);

фізичні моделі процесора, орієнтовані на його реалізацію в конкретних кристалах ПЛІС;

модель системи тестування для перевірки функцій та параметрів процесора;

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

Розділ з описом заданих алгоритмів шифрування та режимів обробки даних Електронна книга кодів (ECB)

Найпростішим з режимів шифрування є режим електронної книги кодів (англ. electronic codebook, ECB). Повідомлення розбивається на блоки і кожен блок шифрується окремо.

Рис. 2 Схеми шифрування і розшифрування режиму електронної кодової книги.

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

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

Ланцюгування шифроблоків (CBC)

IBM винайшла режим ланцюгування шифроблоків (англ. cipher-block chaining, CBC) у 1976. В CBC режимі, кожен блок відкритого тексту XOR-ять з попереднім шифроблоком перед шифруванням. Так, кожен шифроблок, залежить від усіх блоків оброблених до нього. Для отримання унікальних повідомлень потрібно використовувати ініціалізаційний вектор у першому блоці.

Рис. 3 Схеми шифрування і розшифрування режиму ланцюгування шифроблоків.

Якщо перший блок має індекс 1, математична формула для CBC шифрування буде наступною:

тоді як математична формула для CBC розшифрування є такою:

CBC найчастіше використовний режим. Основна його вада це властива послідовність (тобто не можливість упаралелення), і необхідність доповнення повідомлення до розміру кратного розміру блоку. Один зі способів уникнути доповнення полягає в використанні методу викрадення шифротексту. Зауважте, що зміна одного біта в відкритому тексті або IV впливає на всі наступні шифроблоки.

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

Лічильник (CTR)

Подібно до OFB, режим лічильника перетворює блочний шифр в потоковий шифр. Він породжує наступний блок потоку ключа шифруванням послідовних значень «лічильника». Лічильник може бути будь-якою функцією, що видає послідовність, яка гарантовано не повторюється впродовж тривалого часу, насправді найпростішими і найпоширенішими є прості лічильники, що на кожному кроці збільшуються на одиницю. використання простої детерміністичної функції викликає суперечки; критики кажуть, що «навмисне використання відомого систематичного входу в криптосистемі становить непотрібний ризик.» Наразі, режим CTR широко прийнятий, і проблеми похідні від входової функції розпізнаються як слабкість використовного блочного шифру, а не режиму CTR. Проте, існують пристосовані атаки подібні до атаки помилки устаткування (англ. Hardware Fault Attack), які покладаються на використання простого функції лічильника.

Режим CTR має подібні до OFB характеристики, але також має можливість довільного доступу під час розшифрування. Режим CTR добре підходить для використання на багатопроцесорній машині, де блоки можна шифрувати паралельно. Більше того, він не потерпає від проблеми короткого циклу, яка може вплинути на OFB.

Зауважте, що nonce на зображенні це те саме, що й ініціалізаційний вектор на інших зображеннях. IV/nonce і лічильник можна сполучати із використанням будь-якої операції без втрат (конкатенації, додавання або XOR) для отримання унікального блоку лічильника для шифрування.

Рис. 4 Схеми шифрування і розшифрування режиму лічильника.

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

Розділ з описом розробки архітектури пристрою та його структурної схеми на рівні між регістрових передач Розглянемо процес розробки VHDL — моделі пристрою, який реалізує три режими блочного шифрування (ECB, CBC, CTR). Структура пристрою складається з таких елементів: регістри для зберігання вхідних даних, демультиплексорів, мультиплексорів, елементів логічного додавання за модулем два. У складі інтерфейс них ліній є входи синхронізації, входи та виходи даних. В пристрої присутні команди, які задають шифрування чи розшифрування даних (ed) і режим блочного шифрування (em).

Опис інтерфейсу розробленого пристрою є наступним:

entity device is

port (

clk: in std_logic;

rst: in std_logic;

ed: in std_logic;

em: in std_logic_vector (1 downto 0);

data_in: in std_logic_vector (63 downto 0);

key: in std_logic_vector (63 downto 0);

IV: in std_logic_vector (63 downto 0);

data_out: out std_logic_vector (63 downto 0)

);

end device;

На рис. 5 представлена структурна схема пристрою.

Рис. 5 Структурна схема на рівні між регістрових передач.

Спочатку вхідні дані(data_in, key, IV) зберігаються у відповідних регістрах, дальше дані подаються на входи відповідних елементів (мультиплексорів, демультиплексорів, елементів логічного додавання за модулем два).

Розділ з описом розробки VHDL — моделей компонент пристрою та VHDL — пристрою в цілому Згідно із структурною схемою пристрою описуємо елементи які представлені на схемі на мові опису апаратних засобів VHDL. Загальни опис пристрою представлений у файлі device.vhd.

В описі архітектури об’являються 13 підсхем. Після ключового слова begin приводяться екземпляри опису. Кожний екземпляр має карту портів (port map) Карта портів відображає зв’язок між входами, виходами опису компонент і екземплярами компонент.

device.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity device is

port (

clk: in std_logic;

rst: in std_logic;

ed: in std_logic;

em: in std_logic_vector (1 downto 0);

data_in: in std_logic_vector (63 downto 0);

key: in std_logic_vector (63 downto 0);

IV: in std_logic_vector (63 downto 0);

data_out: out std_logic_vector (63 downto 0)

);

end device;

architecture device of device is

signal RS₁_out: std_logic_vector (63 downto 0);

signal RS₂_out: std_logic_vector (63 downto 0);

signal RS₃_out: std_logic_vector (63 downto 0);

signal RS₄_out: std_logic_vector (63 downto 0);

signal MUX₁_out: std_logic_vector (63 downto 0);

signal MUX₂_out: std_logic_vector (63 downto 0);

signal XOR₁_out: std_logic_vector (63 downto 0);

signal AES_out: std_logic_vector (63 downto 0);

signal MUX₃_out: std_logic_vector (63 downto 0);

signal XOR₂_out: std_logic_vector (63 downto 0);

signal counter_out: std_logic_vector (63 downto 0);

signal RS₅_out: std_logic_vector (63 downto 0);

signal DMUX_OUT₁: std_logic_vector (63 downto 0);

signal DMUX_OUT₂: std_logic_vector (63 downto 0);

component RS₁

port (

c: in std_logic;

r: in std_logic;

data_in_RS1: in std_logic_vector (63 downto 0);

data_out_RS1: out std_logic_vector (63 downto 0)

);

end component;

component DMUX

port (

d_in: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

out₁: out std_logic_vector (63 downto 0);

out₂: out std_logic_vector (63 downto 0)

);

end component;

component RS₂

port (

c: in std_logic;

r: in std_logic;

IV_in_RS2: in std_logic_vector (63 downto 0);

IV_out_RS2: out std_logic_vector (63 downto 0)

);

end component;

component RS₃

port (

c: in std_logic;

r: in std_logic;

key_in_RS3: in std_logic_vector (63 downto 0);

key_out_RS3: out std_logic_vector (63 downto 0)

);

end component;

component RS₄

port (

c: in std_logic;

r: in std_logic;

data_in_RS4: in std_logic_vector (63 downto 0);

data_out_RS4: out std_logic_vector (63 downto 0)

);

end component;

component MUX₁

port (

IV_in: in std_logic_vector (63 downto 0);

RG4_in: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

MUX1_out: out std_logic_vector (63 downto 0)

);

end component;

component MUX₂

port (

counter: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

MUX2_out: out std_logic_vector (63 downto 0)

);

end component;

component XOR₁

port (

d_in: in std_logic_vector (63 downto 0);

M1_in: in std_logic_vector (63 downto 0);

M2_in: in std_logic_vector (63 downto 0);

XOR1_out: out std_logic_vector (63 downto 0)

);

end component;

component AES

port (

X_in: in std_logic_vector (63 downto 0);

K_in: in std_logic_vector (63 downto 0);

A_out: out std_logic_vector (63 downto 0)

);

end component;

component counter

port (

c: in std_logic;

r: in std_logic;

count_out: out std_logic_vector (63 downto 0)

);

end component;

component MUX₃

port (

I_in: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

MUX3_out: out std_logic_vector (63 downto 0)

);

end component;

component XOR₂

port (

enc_mode: in std_logic_vector (1 downto 0);

A_in: in std_logic_vector (63 downto 0);

d_in: in std_logic_vector (63 downto 0);

M3_in: in std_logic_vector (63 downto 0);

d_out: out std_logic_vector (63 downto 0)

);

end component;

component RS₅

port (

c: in std_logic;

r: in std_logic;

data_in_RS5: in std_logic_vector (63 downto 0);

data_out_RS5: out std_logic_vector (63 downto 0)

);

end component;

begin

R1: RS₁

port map (clk, rst, data_in, RS₁_out);

D: DMUX

port map (data_in, ed, em, DMUX_OUT₁, DMUX_OUT₂);

R2: RS₂

port map (clk, rst, IV, RS₂_out);

R3: RS₃

port map (clk, rst, key, RS₃_out);

M1: MUX₁

port map (IV, RS₄_out, ed, em, MUX₁_out);

C: counter

port map (clk, rst, counter_out);

M2: MUX₂

port map (counter_out, ed, em, MUX₂_out);

X1: XOR₁

port map (DMUX_OUT₁, MUX₁_out, MUX₂_out, XOR₁_out);

A: AES

port map (XOR₁_out, key, AES_out);

R4: RS₄

port map (clk, rst, AES_out, RS₄_out);

M3: MUX₃

port map (IV, ed, em, MUX₃_out);

X2: XOR₂

port map (em, AES_out, DMUX_OUT₂, MUX₃_out, XOR₂_out);

R5: RS₅

port map (clk, rst, XOR₂_out, RS₅_out);

data_out <= RS₅_out;

end device;

RS₁.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity RS₁ is

port (

c: in std_logic;

r: in std_logic;

data_in_RS1: in std_logic_vector (63 downto 0);

data_out_RS1: out std_logic_vector (63 downto 0)

);

end RS₁;

architecture RS₁ of RS₁ is

begin

process (c, r)

begin

if (r = '1') then data_out_RS1 <= (others => '0');

elsif (c'event and c = '1') then

data_out_RS1 <= data_in_RS1;

else Null;

end if;

end process;

end RS₁;

RS₂.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity RS₂ is

port (

c: in std_logic;

r: in std_logic;

IV_in_RS2: in std_logic_vector (63 downto 0);

IV_out_RS2: out std_logic_vector (63 downto 0)

);

end RS₂;

architecture RS₂ of RS₂ is

begin

process (c, r)

begin

if (r = '1') then IV_out_RS2 <= (others => '0');

elsif (c'event and c = '1') then

IV_out_RS2 <= IV_in_RS2;

else Null;

end if;

end process;

end RS₂;

RS₃.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity RS₃ is

port (

c: in std_logic;

r: in std_logic;

key_in_RS3: in std_logic_vector (63 downto 0);

key_out_RS3: out std_logic_vector (63 downto 0)

);

end RS₃;

architecture RS₃ of RS₃ is

begin

process (c, r)

begin

if (r = '1') then key_out_RS3 <= (others => '0');

elsif (c'event and c = '1') then

key_out_RS3 <= key_in_RS3;

else Null;

end if;

end process;

end RS₃;

RS₄.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity RS₄ is

port (

c: in std_logic;

r: in std_logic;

data_in_RS4: in std_logic_vector (63 downto 0);

data_out_RS4: out std_logic_vector (63 downto 0)

);

end RS₄;

architecture RS₄ of RS₄ is

begin

process (c, r)

begin

if (r = '1') then data_out_RS4 <= (others => '0');

elsif (c'event and c = '1') then

data_out_RS4 <= data_in_RS4;

else Null;

end if;

end process;

end RS₄;

RS₅.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity RS₅ is

port (

c: in std_logic;

r: in std_logic;

data_in_RS5: in std_logic_vector (63 downto 0);

data_out_RS5: out std_logic_vector (63 downto 0)

);

end RS₅;

architecture RS₅ of RS₅ is

begin

process (c, r)

begin

if (r = '1') then data_out_RS5 <= (others => '0');

elsif (c'event and c = '1') then

data_out_RS5 <= data_in_RS5;

else Null;

end if;

end process;

end RS₅;

MUX₁.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity MUX₁ is

port (

IV_in: in std_logic_vector (63 downto 0);

RG4_in: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

MUX1_out: out std_logic_vector (63 downto 0)

);

end MUX₁;

architecture MUX₁ of MUX₁ is

begin

MUX1: process (IV_in, RG4_in, enc_dec, enc_mode)

begin

if (enc_dec='1') then

case enc_mode is

when «00» => MUX1_out <= (others => '0');

when «01» => MUX1_out <= IV_in;

when «10» => MUX1_out <= IV_in;

when others => MUX1_out <= (others => '0');

end case;

end if;

if (enc_dec='0') then

case enc_mode is

when «00» => MUX1_out <= (others => '0');

when «01» => MUX1_out <= (others => '0');

when «10» => MUX1_out <= IV_in;

when others => MUX1_out <= (others => '0');

end case;

end if;

end process;

end MUX₁;

MUX₂.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity MUX₂ is

port (

counter: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

MUX2_out: out std_logic_vector (63 downto 0)

);

end MUX₂;

—}} End of automatically maintained section

architecture MUX₂ of MUX₂ is

begin

MUX2: process (counter, enc_dec, enc_mode)

begin

if (enc_dec='1') then

case enc_mode is

when «00» => MUX2_out <= (others => '0');

when «01» => MUX2_out <= (others => '0');

when «10» => MUX2_out <= counter;

when others => MUX2_out <= (others => '0');

end case;

end if;

if (enc_dec='0') then

case enc_mode is

when «00» => MUX2_out <= (others => '0');

when «01» => MUX2_out <= (others => '0');

when «10» => MUX2_out <= counter;

when others => MUX2_out <= (others => '0');

end case;

end if;

end process;

end MUX₂;

XOR₁.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity XOR₁ is

port (

d_in: in std_logic_vector (63 downto 0);

M1_in: in std_logic_vector (63 downto 0);

M2_in: in std_logic_vector (63 downto 0);

XOR1_out: out std_logic_vector (63 downto 0)

);

end XOR₁;

architecture XOR₁ of XOR₁ is

begin

x: process (d_in, M1_in, M2_in)

begin

XOR1_out <= d_in xor M1_in xor M2_in;

end process;

end XOR₁;

AES.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity AES is

port (

X_in: in std_logic_vector (63 downto 0);

K_in: in std_logic_vector (63 downto 0);

A_out: out std_logic_vector (63 downto 0);

A_dv: out std_logic

);

end AES;

architecture AES of AES is

begin

A: process (X_in, K_in)

begin

A_out <= X_in xor K_in;

end process;

end AES;

MUX₃.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity MUX₃ is

port (

I_in: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

MUX3_out: out std_logic_vector (63 downto 0)

);

end MUX₃;

architecture MUX₃ of MUX₃ is

begin

MUX3: process (I_in, enc_dec, enc_mode)

begin

if (enc_dec='1') then

case enc_mode is

when «00» => MUX3_out <= (others => '0');

when «01» => MUX3_out <= (others => '0');

when «10» => MUX3_out <= (others => '0');

when others => MUX3_out <= (others => '0');

end case;

end if;

if (enc_dec='0') then

case enc_mode is

when «00» => MUX3_out <= (others => '0');

when «01» => MUX3_out <= I_in;

when «10» => MUX3_out <= (others => '0');

when others => MUX3_out <= (others => '0');

end case;

end if;

end process;

end MUX₃;

XOR₂.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity XOR₂ is

port (

enc_mode: in std_logic_vector (1 downto 0);

A_in: in std_logic_vector (63 downto 0);

d_in: in std_logic_vector (63 downto 0);

M3_in: in std_logic_vector (63 downto 0);

d_out: out std_logic_vector (63 downto 0)

);

end XOR₂;

architecture XOR₂ of XOR₂ is

begin

X: process (A_in, d_in, M3_in)

begin

d_out <= A_in xor d_in xor M3_in;

end process;

end XOR₂;

counter_vhd:

library IEEE;

use IEEE. std_logic_1164.all;

use IEEE. std_logic_unsigned.all;

use IEEE. std_logic_arith.all;

entity counter is

port (

c: in std_logic;

r: in std_logic;

count_out: out std_logic_vector (63 downto 0)

);

end counter;

architecture counter of counter is

signal cnt: std_logic_vector (63 downto 0);

begin

count: process (c, r, cnt)

begin

if (r = '1') then cnt <= (others => '0');

elsif (c'event and c = '1') then

cnt <= cnt+'1';

else cnt <= cnt;

end if;

end process;

count_out <= cnt;

end counter;

DMUX.vhd:

library IEEE;

use IEEE. STD_LOGIC_1164.all;

entity DMUX is

port (

d_in: in std_logic_vector (63 downto 0);

enc_dec: in std_logic;

enc_mode: in std_logic_vector (1 downto 0);

out₁: out std_logic_vector (63 downto 0);

out₂: out std_logic_vector (63 downto 0)

);

end DMUX;

architecture DMUX of DMUX is

begin

D: process (d_in, enc_dec, enc_mode)

begin

if (enc_dec='1') then

case enc_mode is

when «00» => out₁ <= d_in; out₂ <= (others => '0');

when «01» => out₁ <= d_in; out₂ <= (others => '0');

when «10» => out₁ <= (others => '0'); out₂ <= d_in;

when others => out₁ <= (others => '0'); out₂ <= (others => '0');

end case;

end if;

if (enc_dec='0') then

case enc_mode is

when «00» => out₁ <= d_in; out₂ <= (others => '0');

when «01» => out₁ <= d_in; out₂ <= (others => '0');

when «10» => out₁ <= (others => '0'); out₂ <= d_in;

when others => out₁ <= (others => '0'); out₂ <= (others => '0');

end case;

end if;

end process;

end DMUX;

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

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

Структуру типової системи тестування програмних моделей представлено на рис. 1 .

Рис. 6. Структура типової системи тестування програмних моделей процесорів.

На вхід тестованого пристрою подають вхідні тестові набори, результати обробки яких порівнюють з зразковими значеннями — вихідними тестовими наборами. Порівняння результатів обробки вхідних тестових наборів і зразкових значень виконує пристрій порівняння. Результат його роботи визначає коректність (чи некоректність) функціонування тестованого пристрою. Функції керування тестованим пристроєм та пристроєм порівняння виконує пристрій керування системою тестування. Сигнали синхронізації та початкового скиду системи зазвичай подають ззовні.

Результати симуляції пристрою є наступними:

Рис. 7 Результат симуляції розшифрування даних в режимі CTR.

Рис. 8 Результат симуляції розшифрування даних в режимі CBC.

Рис. 9 Результат симуляції розшифрування даних в режимі CTR.

Cинтез розробленої VHDL — моделі пристрою в ПЛІС Для синтезу розробленої VHDL — моделі пристрою в ПЛІС використовуємо програму Xilinx ise. Спочатку необхідно створити проект і вибрати параметри проекту. Параметри проекту які використані у даній курсовій роботі представлені на рис.10:

Рис. 10 Параметри проекту.

Наступним кроком є перевірка коду на синтаксичні помилки. Це здійснюється за допомогою команди Check Syntax. Після успішної перевірки синтаксису здійснюємо побудову ПЛІС за допомогою команди Implement Top Module. Після побудови ми отримаємо схему ПЛІС (рис. 11,12).

Рис. 11 схема ПЛІС.

Рис. 12 схема ПЛІС.

Також ми отримаємо характеристики програмованої логічної інтегральної схеми (рис. 13,14,15)

Рис. 13 характеристики ПЛІС.

Рис. 14 характеристики ПЛІС.

Рис. 13 характеристики ПЛІС.

Висновки Під час виконання даної курсової роботи я узагальнив знання, отримані під час вивчення навчальної дисципліни «Комп`ютерні методи високорівневого проектування пристроїв захисту», та трансформував ці знання в практичні навички для побудови пристрою, який здійснює три режими блочного шифрування (ECB, CBC, CTR). В пристрої присутні команди, які задають шифрування чи розшифрування даних (ed) і режим блочного шифрування (em). Для побудованого пристрою була розроблені програма тестування.

В даній роботі за допомогою програми Xilinx ise розроблений пристрій був реалізований на програмованій логічній інтегральній схемі. До отриманої ПЛІС були представлені характеристики і структурна схема.

Список використаної літератури Коркішко Т.А., Мельник А. О., Мельник В. А. Алгоритми та процесори симетричного блокового шифрування. / Львів, БАК, 2003. — 182 с.

FFPS 46, «Data Encryption Standard», Federal Information Processing Standard (FTPS), Publication 46, National Bureau of Standards, U.S. Department of Commerce, Washington D.C.

FEPS 81, «Operational modes of DES», Federal Information Processing Standard (FIPS), Publication 81, National Bureau of Standards, U.S. Department of Commerce, Washington D.C.

ГОСТ 28 147–89. Система обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. М. Госстандарт СССР

Daemen J., Rijmen V. AES Proposal: Rijndael // First Advanced Encryption Standard (AES) Conference. — Ventura, CA, 1998.

VHDL + Verilog = синтез за минуты: Учебное пособие/ В. И. Хаханов, И. В. Хаханова.-Харьков: ХНУРЭ.- 2006. 264 с.

В.А. Мельник, В. Б. Дудикевич. «Тестування генераторів ядер комп’ютерних пристроїв» // Вісник Національного університету «Львівська політехніка» «Автоматика, вимірювання та керування». — 2003. № 475. — с. 123−128.

Угрюмов Е. П. Цифровая схемотехника. — СПб.: БХВ-Петербург, 2000. — 528 с.

Суворова Е.А., Шейнин Ю. Е. Язык VHDL для проектирования систем на СБИС: Учебное пособие. / ГУАП, СПб., 2001 — 212 с.

Мясников В А., Игнатьев М. Б., Кочкин А. А., Шейнин Ю. Е. Микропроцессоры: системы программирования и отладки. М: Энергоатомиздат, 1985. — 272 с.

Майоров С.А., Новиков Г. И., Алиев Т. И. Основы теории вичислительных систем. — М.: Высш.шк., 1978.-408 с.

ГОСТ Р 50 754−95. Язык описания аппаратуры цифровых систем VHDL. Описание языка.