Есть предположение, что скоро поставят задачу реализации шифрования Ethernet трафика по ГОСТ на плисе.

Надо будет шифровать 2-4 потока гигабитного ethernet, работать желательно без потери скорости.

Кто с этим сталкивался порекомендуйте какую плис лучше использовать?

Плис желательно со встроенными высокоскоростными трансиверами, т.е Spartan6, Cyclone4, Arria.

Нужна ли будет внешняя память, и если нужна, то примерно какой объем?

У меня такое чувство, что Вы задаете вопросы, ответы на которые появятся примерно на середине работы над проектом .

угу, потому и спрашиваю, чтобы время зря не терять. Кто-нибудь на форуме наверняка делал.

Вы имеете ввиду ГОСТ 28147-89? я его начинал делать, ради эксперимента, и не на такие скорости.. но потом эта задача отпала. но работу в режиме простой замены почти доделал.
я бы посоветовал применить VIRTEX6, хотя думаю и Spartan6 с лихвой хватит и думаю что внешняя память будет не нужна, т.к. нет в алгоритме таких больших массивов данных которые не уместятся в BlockRAM плиски...

wolfman, а Вы планируете делать "проточный" Ethernet шифратор ? то есть с одной стороны будет заходить незашифрованный пакет Ethernet, с другой будет выходить он же, но зашифрованный ? Или эти Ethernet пакеты будут заходить/выходить в компьютер ?
Если речь идет о Full Duplex, то даже при 50% утилизации ОДНОГО гигабитного линка получаем поток 1e9/8/1e6*0.5 = 62.5 МБайт/сек. У нас люди делали шифраторы по ГОСТ. Скорость одного шифратора на Cyclone 4 получалась ~ 12 МБайт/сек. Таким образом на обработку такого потока Вам понадобится поставить не менее 5 шифраторов. Из этих цифр можно также попробовать оценить необходимые объемы памяти. Даже в микросхеме Arria встроенной памяти для буферизирования перед шифрованием такого потока данных вряд ли хватит (хотя с очень большими кристаллами Arria дел не имел)

Либо что-то не то у Вас люди делали, либо Xilinx получше для этой задачи подходит.

По Xilinx у меня такие данные:
Spartan2E - 64 MHz (16 Мбайт/c)
Spartan3 ~ 120 MHz (30 Мбайт/c)
Virtex5 ~200 MHz (точно уже не помню, но частота определялась не ГОСТом) (50 Мбайт/c)

Если использовать несколько вычислителей, то поскольку пакеты разной длины, порядок их на выходе может меняться. Спартана 6 должно хватить. Только над ключевой системой Вам придется крепко подумать (возможно из этого вылезут какие-то требования по памяти), особенно если устройство предполагается сертифицировать.

Почти любую, внешняя память не понадобится.
Плата сетевого шифратора для шины PCI Express
В настоящий момент поставляются карты на скорость 100 Мбит. Гигабитного шифратора в списке поставляемой продукции нет.

да, именно так и планирую.

to BSV
сертифицировать обязательно будем.

Если встроенной памяти будет не хватать всегда можно использовать внешнюю, DDR2 или DDR3. или могут быть проблемы?

to ALL
Ребята всем спасибо, буду думать.

Не сталкивался, но похоже, что даже самый слабый 6-й Спартан должен потянуть. Но готовьтесь к параллельной обработке 4-8 независимых потоков данных на поток Ethernet. Впрочем, возможно хватит и двух.

Ох и огребете вы проблем с проходным шифратором. Для начала самая простая проблема - размер пакета. Неужели вы собираетесь шифровать все пакеты на одном и том же ключе? Такое решение никто не сертифицирует. В противном случае придется каким-то образом удлиннять пакет, чтобы вставить в него информацию о ключе. Как вы собираетесь делать это, не нарушая стандарта?

Ставится коробочка с шифрованием Ethernet после ПК и по кабелю уже передаются шифрованные данные. Эти шифрованные данные поступают на коробочку, которая дешифрует и в ПК поступает обычный Ethernet. В итоге по кабелю идет только шифрованная информация.
Пример такой коробочки


Я не сталкивался, но думаю, что вот такая плата на Xilinx SP605 должна подойти.

Как говорится: глаза боятся, а руки делают...

Думаю все же заложиться на 4-ый сыклон 150-ку, 800 бакинсих.




К сожалению это не вариант.

А чем предложенная плата не подошла?
Дешевле 800$

Раз уж речь идет про ГОСТ.
Ключевая система уже есть? Согласована?
Само устройство сертифицировать собираетесь и под какую категорию?
Проблема не столько в том, чтобы сделать, а в том чтобы сделать устройство, которое работает и поддается сертификации.

Я практически на ПЛИС не делал, но примерялся - шифрование-деширование по 28147 в режиме простой замены требует 16 раундов для 64-битного блока. То есть - 2 такта на байт, это теоретический предел без использования конвееризации. А с конвееризацией можно теоретически поднять то 8 байтов на такт. То есть 100МГц Спартан с полным конвеером (займет 1К+ триггеров) вполне выдаст 800Мбайт/сек - c временным разделением вполне 4-8 гигабитных потока пропускается.

Шифруется ethernet или ip-пакеты? Судя по ссылкам везде приводится ip

Для отладки может быть и подойдет, а для готового устройства нет, ибо нету тама писиая.





Да пока мест изучаю, задания нету еще. Может и не будет.
Знаю только, что модуль шифрования нужен и я делал платку на готовом чипе, но вчера производитель чипа "порадовал" тем, что снимает его с производства и прекращает всяческую поддержку. Потому и задался вопросом, что придется делать в плисе, а если делать, то соответственно гостовский.





Пока еще не знаю. Данный модуль будет встроен в маршрутизатор, так что вполне возможны разные варианты.

Ответ выделил жирным текстом

или Вам обычный PCI нужен?

у меня в обще нет ни PCI, ни PCI Express.
Этот модуль будет использоваться в составе маршрутизатора(не в ПК), в маршрутизаторе есть процессор, но с ним связь только через MDIO.
Если на этот модуль ставить дополнительный процессор, то наверное, весь смысл теряется. Проще тогда поставить процессор и на нем все делать.

а точно нужно Езернет шифровать? Насколько я понимаю, в наше время езернет в открытом виде уже по всем точкам подключения не ходит, а присутствует только в свичах. Хабы уже не делают. Кроме того, у всех пользователей должен быть один и тот же ключ, что существенно ослабляет схему.
А для шифрования точка-точка лучше что-то стандартизованное использовать. Какой-нибудь ipsec, skip... Это поверх ip, но зато специфицированно.

Вопрос, если шифровать IP-пакеты. Из Ethernet кадра вытаскиваем IP-пакет, шифруем, затем нужно ли его заново упаковывать в IP-пакет, ведь он станет больше по размеру или же можно сформировать обычный Ethernet-кадр?

Или же потрошим не только Ethernet-кадр, но и IP-пакет, данные IP-пакета шифруем, собираем новый IP-пакет и передаем?

Или все это должно задаваться на уровне ТЗ?

Ммм... Вы уверены?

А что не так?

Вроде бы наоборот надо.

Хм, я могу ошибаться, но разве формат кадров не такой?

Нажмите для просмотра прикрепленного файла

т.е IP-пакет, внутри Ethernet-кадра.

Да. Пора спать. Сорри.
Вообще, обычно пересобирают IP-пакеты.

Ничего, бывает. У меня самого голова раскалывается, тоже пойду на боковую.

Мне кажется всё зависит от того, где стоит дешифратор. Если дешифратор в локальной сети, то до него дойдёт и RAW Ethernet frame, а если он где нибудь в Америке, то через кучу маршрутизаторов без IP не продраться.

ок, надо будет подумать.

Лучше шифровать IP-пакет целиком, так скрывается структура защищаемой сети. Также нужно обязательно формировать новый IP-заголовок, причину выше описали. Дополнительно можно предусмотреть имитозащиту передаваемых данных/служебных данных (+имитовставка(и)). Так как пакеты становятся больше, их при превышении MTU нужно фрагментировать. Можно еще ограничить MTU защищаемой сети с таким расчетом, чтобы размер зашифрованных пакетов не превышал MTU.

В любом случае нужно начать с ТЗ - согласовать с организацией, которая будет сертифицировать устройство, ключевую систему, основные алгоритмы, дополнительные средства защиты и т.п. Иначе в процессе сертификации могут возникнуть непреодолимые без переделки железа проблемы.

Кстати, ГОСТ уже далеко не передний край отечественной науки и имеет некоторые ограничения при применении, а в некоторых случаях вовсе неприменим. Самое смешное, что достойной альтернативы ему нет. Алгоритмы-то есть, но они либо закрыты, либо гораздо медленнее при реализации на текущем железе, либо и то и другое вместе.

Я с утра, вроде, понял, что сам же хотел сказать.
IP-пакеты больше по размеру, чем езернет-кадры. Вот.

Полностью согласен.

Сразу видно, человек имеет реальный опыт работы в данной области.

Хм... С этого нужно было начинать. Зачем что-то вообще шифровать, если нет цели передать и потом расшифровать, причем, так, чтобы даже богатый и умный шпиён ничего не мог понять? Чтобы в рекламе написать про шифрование? Ну тогдо просто проксорьте последовательность с ключем.

Вы классиков, конечно, уже читали? http://www.schneier.com/book-applied.html

то что с ТЗ надо начинать это понятно, но обычно ТЗ формулируется так: копать отсюда и до обеда.

А если серьезно, то просто хотел прикинуть на какую, примерно, плис рассчитывать, если все правильно делать.
Так же теперь понятно, что должно включать ТЗ.

Ethernet шифровать значительно проще, но, редко когда это бывает нужно (почти бессмысленно)...
А вот с шифрованием IP столько подводных камней, что все равно, все, кто пробует это реализовать, приходят к какому-то подобию IPSEC-а.
В нем есть 2 стадии: 1- стадия установления соединения. Это протокол ISAKMP. На этом этапе вырабатывается общий ключ для шифрования трафика. Если ключ прописывать заранее, то стадию можно опустить или значительно упростить. Этот обмен проходит по протоколу UDP, обычно с/на 500 порт.
2- стадия, собственно шифробмен. Пакеты пакуются в ESP с дописыванием векторов инициализации и контрольных сумм и/или подписей.
В ПЛИСах реализовывать все это слишком муторно. Можно первую стадию реализовать на каком-нибудь процессоре, а ПЛИС использовать только как криптоакселератор для второй стадии. Обычно, в маршрутизаторах так и делают...

оки, спасибо.

Ребята ткните носом: как на вхдл реализуется сложение по модулю 2^32?

signal A,B,C : STD_LOGIC_VECTOR(31 downto 0);
...

C <= A + B;

Ну Вы даете

А не на VHDL?

Да, я уже понял, просто сложно сосредоточится, когда дети мягко говоря шалят за спиной, все время отвлекая...

Что-то я к вечеру вообще

чтобы не плодить новые темы: подскажите как прошивать плис через внешний процессор, и схемку если можно?

Из описания Альтеры не очень понятно как это делается.

Сделал я реализацию ГОСТа в режиме простой замены. Сейчас есть два варианта: первый не оптимизированный, работает примерно за 128 тактов.
Второй, оптимизированный, работает за 36 тактов(32 такта само шифрование + некоторая доп. задержка).

Причешу не оптимизированный и могу выложить на форуме, если надо (до оптимизировать будет не сложно).

Кто-бы ткнул носом как правильно организовывать и управлять очередями?
Вечером буду искать по форуму, вроде бы где-то видел.

Ммм... А разве такую штуку можно выкладывать ??

Формально, наверное, нельзя.
Но там ни ключей, ни таблиц замены нет. Также это только реализация алгоритма ГОСТ в режиме простой замены. Остальную часть проекта я же не выкладываю.

Ну, скажем, если подумать, то для простой замены такта 3 (без учета загрузки первого блока в накопители) еще можно соптимизировать.
Выкладывать можно и формально и неформально, ничего в ГОСТе особенного нет.

Я делал нечто подобное. Мой совет поговорите с теми, кто будет сертифицировать ваш продукт. Только они могут сказать что именно нужно сделать. И передавайте привет "группе полковников"

Потому как по моему разумению, реализация режима простой замены - только 10% работы. Шифровать поток в режиме простой замены запрещено, это только 32-х раундовая основа шифрования. Сертифицированное оборудование шифрует данные только в режимах гаммирования или гаммирования с обратной связью, которые в свою очередь, основаны на режиме простой замены. Это первая ваша головная боль.

Вторая проблема - это расспределение ключевой информации. Так как ГОСТ - система симметричного шифрования, то вам нужно будет желать систему распределения ключей между абонентами. Это либо передача физичеких носителей между абонентами - так называемый "ключевой блокнот", либо вставка ассиметричного протокола с распределением ключей.

Третья боль - ГОСТ реализует блочный алгоритм шифрования. Если у вас шифруются пакеты разной длины (как пример ip_v4 и ip_v6) придется делать некий парсер входящей информации.

Четвертая проблема знакома мне только по слухам и потому воспринимайте её не более чем слух - это уязвимость в выработки имитовставки. Что с ней вообще придется делать и придется ли вообще - не знаю.

Но в любом случае - желаю большой удачи.

Спасибо.
На счет сертификации пока туманно.
Сейчас появилось некое подобие ТЗ. Про гаммирование ничего нет, возможно сам сделаю, если будет время.
Распределением ключевой информации будет заниматься отдельный процессор и в этом есть свой плюс и, к сожалению, минус.

Да в иммитовставке действительно есть уязвимость, но и без этого головняка действительно очень много выходит.

Еще раз спасибо.