По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Зачем нужно шифрование и насколько оно важно?
Функционирование любых цифровых сервисов невозможно без защиты данных. Еще совсем немного времени назад эта проблема не стояла так остро, так в основной массе устройств использовались относительно защищенные каналы связи. Типичный пример - телефонный кабель между персональным компьютером и провайдером. Даже, если по нему передаются незашифрованные данные, то их похитить затруднительно из-за объективных сложностей физического доступа к телефонной линии, особенно когда она проложена под землей, как это делается в городах. Теперь же, когда все, включая даже финансовые переводы, делается с мобильных устройств, ни о какой защите канала связи не может быть и речи, причем, так как радиоэфир доступен каждому. Значительное количество Wi-Fi карт довольно просто переводятся в режим мониторинга и могут принимать данные, передаваемые другими устройствами. Выход из этой ситуации заключается в использовании совершенных алгоритмов шифрования. Причем к этому решения одновременно пришли многие IT-разработчики в мире. Совершенно определенно, что алгоритмы шифрования должны быть стандартными, принятыми во всех странах мира, так как интернет глобален. При несоблюдении этого правила, то, что передается одним сервером, уже не может быть принято другим, так как алгоритм шифрования не известен. Итак, теперь понятно, что без общепринятых, сертифицированных и надежных алгоритмов шифрования не обойтись.
Алгоритм 3DES или Triple DES
Самый первый, принятый для использования в сети интернет алгоритм шифрования. 3DES разработан Мартином Хеллманом в 1978 году. Учитывая уже почетный возраст для IT-технологий, по оценкам НИСТ (Национальный Институт Стандартов и Технологий) он останется надежным до 2030-х годов. Несмотря на достаточное количество более современных и значительно более криптостойких алгоритмов, банковские системы продолжают использовать именно старый добрый 3DES, что косвенно говорит о его высокой надежности. Также он активно используется в сети интернет во всем мире. Рассмотрим его работу подробнее. Ну, а самое интересное - почти все более современные алгоритмы шифрования представляют собой доработанный DES. Даже утвержден неформальный термин, как "DES-подобные криптографические системы".
В 1977 совместными усилиями многих разработчиков из компании IBM создается алгоритм DES (Data Encryption Standard, "Данные Шифрования Стандарт"), который утверждается правительством США. Всего через год на его основе появится доработанный вариант - 3DES, который предложит Мартин Хеллман и он тоже будет утвержден, как улучшенная версия. DES работает на так называемой сети Фейстеля. Это ни что не иное, как модульные вычисления - многократно повторяемая простая вычислительная операция на нескольких логических ячейках. Именно с этого конца смотрят хакеры, когда для подбора ключей используются майнинг-фермы на процессорах с тысячами ядер CUDA (в видеокартах). Так какие же вычисления выполняет "взломщик"? Ответ - разложение на простые множители или факторизацию с некоторыми дополнительными операциями.
Для числа из трех знаков, разложение на простые множители займет несколько минут ручного пересчета, или миллисекунды работы компьютера. Пример - число 589, для которого ключ будет равен 19*31=589. На самом деле, алгоритмы шифрования работают очень просто. Попробуем методом факторизации, известным очень давно, скрыть ключ. Пусть ключом у нас будет число длиной 30 знаков (при работе с байтами и битами это могут быть и буквы). Добавим к нему еще одно число такой же (или отличающейся, это неважно) длины и перемножим их друг на друга:
852093601- 764194923 - 444097653875 х
783675281 - 873982111 - 733391653231 =
667764693545572117833209455404487475025224088909394663420125
Нам сейчас важно то, что на это перемножение мы затратили ничтожную вычислительную мощность. С таким простым умножением можно справиться даже без калькулятора, затратив несколько часов времени. Калькулятор, а там более мощный компьютер сделает это за тысячную долю секунды. Если же мы поставим обратную задачу - восстановить исходные множители, то на это даже на мощном компьютере уйдут годы, и это время будет увеличиваться квадратично по мере прибавления знаков в исходных числах. Таким образом, мы получили одностороннюю функцию, являющуюся базовой для всех распространенных алгоритмов шифрования. Именно на односторонних функциях (хеширование) построен DES, 3DES и последующие (AES) способы защиты информации. Перейдем к их более подробному рассмотрению.
Алгоритм AES
На данный момент времени самый распространенный алгоритм шифрования в мире. Название расшифровывается, как Advanced Encryption Standard (расширенный стандарт шифрования). AES утвержден национальным институтом технологий и стандартов США в 2001 году и в активном применении находится до сих пор. Максимальная длина шифроключа - 256 бит, что означает, что пароль может иметь до 32 символов из таблицы на 256 значений (кириллица, латиница, знаки препинания и другим символы). Это достаточно надежно даже для современного мира с мощными компьютерными мощностями для перебора (брутфорса). В 16-ричной системе счисления AES может иметь и более длинные ключи, но криптостойкость их точно такая же, ибо конечное число всех возможных вариантов идентичное, вне зависимости от системы счисления.
Специалисты не раз отмечали, что в отличие от других шифров AES имеет простое математическое описание, но такие высказывания подвергались критике и опровергались математиками с указаниями ошибок в уравнениях. Тем не менее, Агентство Национальной Безопасности США рекомендует AES для защиты самых важных сведений, составляющих государственную тайну, а это тоже отличный показатель надежности. Ниже приведена блок-схема шифрования AES.
Отметим, что разработка алгоритмов шифрования дело не столь сложное, как кажется на первый взгляд. Например, по заверению многих студентов при прохождении предмета "основы криптографии" они разрабатывали собственные "несложные" алгоритмы, наподобие DES. Кстати, все тот же DES имеет множество "клонов" с небольшими нововведениями разработчиков в России и других странах.
Российские алгоритмы шифрования
Одним из первых шифров, который утверждался официально, стал принятый в 1990 году ГОСТ 28147-89, разработанный на все той же сети Фейстеля. Конечно, алгоритм был разработан почти на целое поколение раньше, и использовался в КГБ СССР, просто необходимость его обнародования возникла только в эпоху цифровых данных. Официально открытым шифр стал только в 1994 году. Шифр "Калина" (тот же ГОСТ 28147-89 для России и ДСТУ ГОСТ 28147:2009 для Украины) будет действовать до 2022 года. За этот период он постепенно будет замещен более современными системами шифрования, такими, как "Магма" и "Кузнечик", поэтому для более подробного обзора в этой статье интересны именно они.
"Магма" и "Кузнечик" стандартизованы ГОСТ 34.12-2018. Один документ описывает сразу оба стандарта. "Кузнечик" шифрует любые данные блоками по 128 бит, "Магма" - 64 бита. При этом в "Кузнечике" кусок данных в 128 бит шифруется ключом по 256 бит (34 байта, или пароль в 32 знака с выбором из 256 символов). Миллионы блоков данных шифруются одним ключом, поэтому его не нужно передавать с каждым сообщением заново. То, что ключ занимает больший объем, чем данные, никак не сказывается на работе алгоритма, а только дополнительно придает ему надежности. Конечно, "Кузнечик" разработан не для тех систем, где на счету каждый килобайт, как например, в узкополосной радиосвязи. Он оптимально подходит для применения в IT-сфере. Описание математического аппарата "Кузнечика" - тема отдельной статьи, которая будет понятна лишь людям хотя бы с начальным знанием математики, поэтому мы этого делать не будем. Отметим лишь некоторые особенности:
Фиксированная таблица чисел для нелинейного преобразования (приведена в ГОСТ 34.12-2018).
Фиксированная таблица для обратного нелинейного преобразования (также приведена в ГОСТ 34.12-2018).
Многорежимность алгоритма для способов разбивания шифруемого потока данных на блоки: режим имитовставки, гаммирования, режим простой замены, замены с зацеплением, гаммирования с обратной связью.
Помимо шифрования данных "Кузнечик" и "Магма" могут быть использованы для генерации ключей. Кстати, именно в этом была обнаружена их уязвимость. Так, на конференции CRYPTO 2015 группа специалистов заявила, что методом обратного проектирования им удалось раскрыть алгоритм генерации ключей, следовательно, они не являются случайной последовательностью, а вполне предсказуемы. Тем не менее, "Кузнечик" вполне может использоваться для ручного ввода ключа, а это полностью нивелирует данную уязвимость.
Большое преимущество алгоритма "Кузнечик" - он может применяться без операционной системы и компьютера. Необходимы лишь маломощные микроконтроллеры. Этот способ описан в журнале Радиопромышленность том 28 №3. По той же технологии возможна разработка прошивок контроллеров и под другие алгоритмы шифрования. Такое решение под силу реализовать на аппаратной основе (микросхемы) даже в любительских условиях.
Любительские разработки
В конспирологических кругах распространено мнение об уязвимости стандартных алгоритмов шифрования, хотя они давно уже описаны математически и легко проверяются. Есть даже способ "майним биткоины на бумаге", то есть, используя карандаш и лист бумаги, давно было показано, как предварительно переведя данные в шестнадцатиричную систему, их зашифровать и расшифровать стандартным алгоритмом SHA-256, подробно изъяснив каждый момент на пальцах. Тем не менее, находятся люди, желающие разработать свой собственный алгоритм шифрования. Многие из них - студенты, изучающие криптографию. Рассмотрим некоторые интересные способы реализации таких шифров и передачи ключей.
Использование картинки для составления ключа и передачи данных. Способ часто применяется для передачи небольших блоков, например ключей. Изменения (растр, фиксируемой программой шифрации/дешифрации) не должны быть заметны простому зрителю.
Использование видео. Собственно, это вариант первого способа. Просто, в отличие от картинки, в видео можно зашифровать уже более значительный трафик, например, голосовой обмен в реальном времени. При этом требуется высокое разрешение картинки, что для современных мультимедийных устройств - не проблема.
Встраивание данных в аудио. Разработано множество программных продуктов для решения данной задачи, получены соответствующие патенты, например, "Патент США 10,089,994" на "Аудио водяные знаки".
Простые шифры замены на основе словарей, например, Библии, или менее известной литературы. Способ шифрования хорошо знаком по шпионским фильмам и наиболее прост для любительского применения.
Динамичные ключи, автоматически изменяемые по параметрам устройства. Например, отслеживается 100 параметров ПК (объем диска, температура процессора, дата и время) и на их основе программа автоматически генерирует ключ. Способ очень удобен для автомобильных сигнализаций, считывающих все параметры по шине CAN.
Способов шифровать данные огромное множество и все их можно разделить на шифр замены и шифр перестановки, а также комбинацию этих обоих способов.
Алгоритмы шифрования и криптовалюты
Совершенствование алгоритмов шифрования стало одним из основных факторов возникновения всемирного бума криптовалют. Сейчас уже очевидно, что технология блокчейн (в основе нее лежат все те же алгоритмы шифрования) будет иметь очень широкое применение в будущем.
Для выработки криптовалют (майнинга) используются разнообразные компьютерные мощности, которые могут быть использованы для взлома различных алгоритмов шифрования. Именно поэтому в криптовалютах второго и последующих поколений эту уязвимость постепенно закрывают. Так Биткоин (криптовалюта первого поколения) использует для майнинига брутфорс SHA-256 и майнинг-ферма с небольшой перенастройкой может быть использована для взлома данного алгоритма. Эфириум, уже имеет свой собственный алгоритм шифрования, но у него другая особенность. Если для биткоина используются узкоспециализированные интегральные микросхемы (асики), неспособные выполнять никаких других операций, кроме перебора хешей в SHA-256, то эфириум "майнится" уже на универсальных процессорах с CUDA-ядрами. Не забываем, что криптовалюты только начали свое шествие по миру и в недалеком будущем эти недостатки будут устранены.
Плата ASIC-майнера содержит одинаковые ячейки со специализированными процессорами для перебора строк по алгоритму шифрования SHA-256
Алгоритмы шифрования и квантовый компьютер
Сделав обзор по современным алгоритмам шифрования, нельзя не упомянуть такую тему, как квантовый компьютер. Дело в том, что его создатели то и дело упоминают о "конце всей криптографии", как только квантовый компьютер заработает. Это было бы недостойно обсуждения в технических кругах, но такие заявления поступают от гигантов мировой индустрии, например транснациональной корпорации Google. Квантовый компьютер обещает иметь чрезвычайно высокую производительность, которая сделает бесполезной криптографию, так как любое шифрование будет раскрываться методом брутфорса. Учитывая, что на шифровании, в некотором смысле, стоит современный мир, например финансовая система, государства, корпорации, то изобретение квантового компьютера изменит мир почти также, как изобретение вечного двигателя, ибо у человечества уже не будет основного способа скрывать информацию. Пока, что, заявления о работающей модели квантового компьютера оставим для обсуждения учеными. Очевидно, что до работающей модели еще очень далеко, так, что криптографические алгоритмы продолжат нести свою службу по защите информации во всем мире.
В данной статье мы рассмотрим процессы CICD автоматизации.
Разберем роль такого продукта, как Jenkins и его аналогов. Программное обеспечение Jenkins написано на языке программирования Java, по отзывам ИТ сообщества, данный продукт написан очень хорошо. Но самое главное данное программное обеспечение полностью бесплатное. Многие энтузиасты в мире для данного продукта пишут плагины, которые расширяют функционал Jenkins. Рассмотрим 2 ключевых понятия CICD Автоматизации.
CI – Continuous Integration. Это DevOps модель, в которой разработчики делают commit кода в репозиторий (обычно используется github или gitlab, для хранения кода) и автоматически запускается build или компиляция этого кода, после этого запускаются автоматические тесты кода: Unit Test, Integration Test, Functionality Test.
CD – Continuous Delivery and Deployment. Это DevOps модель, в которой разработчики делают commit кода в репозиторий и автоматически запускается build или компиляция этого кода, после этого запускаются автоматические тесты кода и готовый Artifact (скомпилированный код, например если это Java, то артефактом является var, если это Android приложение, то apk файл) делает деплой в Staging и Production, т.е происходит установка кода в развернутую вашу среду в необходимом контуре. Рассмотрим процесс на примере.
Процесс CICD автоматизации
Первым шагом в процессе является Commit to Source Control (github, gitlab или bitbucket), система определяет наличие нового кода, срабатывает триггер и автоматически запускается следующий этап BuildCompile - компиляция кода.
Система скачивает новый код, например, если код попал в master branch (основную ветку). После получения ответа от сборки, что все прошло успешно, запускается следующий этап тестов. Все тесты пишут все те же программисты, для того, чтобы проверить на сколько корректно отработал код. Весь этот процесс называется Continuous Integration. Это классическая схема содержит 3 этапа, иногда включаются дополнительные шаги, но они не принципиальны. В результате данного процесса мы получаем скомпилированный и протестированный код.
Давайте рассмотрим последующие шаги. Следующий шаг мы можем сделать deployment кода. По сути это тот же процесс копирования файлов кода на сервера. Процесс деплоя можно делать в разные места, можно делать в AWS или Azure, можно делать в свое частное облако, развернутое на VMware. Весь процесс с добавочными шагами называется Continuous Delivery and Deployment.
Получается следующее: за Source Control – отвечает git. За шаг build и compile будет отвечать Jenkins. Следовательно, Jenkins запустится, когда кто-нибудь сделает комит в систему контроля версий, в основную ветку или не основную, смотря как настроено. Следующим шагом Jenkins выполнит все необходимые тесты, которые подготовили программисты. Следующий шаг Deploy так же запустит Jenkins и скопирует код на необходимые сервера, с помощью скрипта или scp если это Linux сервер. Существуют вариации с использованием Puppet или Ansible если мы делаем Deploy артефакта или конфигурации в целом.
Существуют альтернативы Jenkins, например, Bamboo, Circleci, Gitlab CICD, TeamCity.
Установка Jenkins
Для развертывания Jenkins нам понадобится виртуальная машина на Ubuntu версии 18 или выше.
Идем на официальный сайт Jenkins,в разделе Download мы можем увидеть 2 версии. На момент написании статьи актуальная версия Jenkins 2.319.2LTS и во второй колонке мы можем увидеть недельные версии Jenkins 2.333
Как видите дистрибутивы есть практически под все операционные системы. Мы будем использовать стабильную версию под UbuntuDebian. Ознакомимся с требованиями к установке продукта Jenkins. Для инсталляции потребуется минимум 256 МБ RAM, места 1 ГБ, а также на сайте написаны рекомендованные требования, с которыми будет достаточно комфортно работать с продуктом.
Так как Jenkins написан на Java, то для запуска и работы потребуется непосредственно установленная на сервере Java. Для начала проверим версию java на сервере.
java –version
Если сервер свежий или Java не установлена, то операционная система сообщит, что такая команда не найдена и предложить установить Java. Java устанавливается достаточно просто:
sudo apt update – oбновляем репозиторий
sudo apt search openjdk – ищем необходимый пакет
sudo apt install openjdk-11-jdk – запускаем установку java в процессе система попросит подтвердить. Чтобы предупреждение не выскочило мы можем запустить установку с ключем –y
По окончанию установки мы опять проверяем версию. Система покажет версию и билд Java. Теперь наш сервер готов к началу установки Jenkins.
Добавляем ключ и репозиторий в операционную систему:
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo tee
/usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc]
https://pkg.jenkins.io/debian-stable binary/ | sudo tee
/etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt-get update – обновляем репозиторий
sudo apt-get install Jenkins – инсталлируем непосредственно сам Jenkins
Теперь мы можем сделать пост настроечные мероприятия непосредственно в Jenkins.
Открываем браузер и переходим на веб интерфейс http://ipaddr:8080, где вместо ipaddr – подставляем IP адрес сервера. В ответ получаем вот такое сообщение - Unlock Jenkins
Система просит ввести дополнительный ключ, который был сгенерирован при установке сервера. Найти его достаточно просто достаточно ввести в консоли сервера
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
Копируем и вставляем в веб форму. После прохождения этой несложной системы безопасности мы можем начать базовую настройку.
Система предлагает выбрать стандартную установку или кастомизированную с выбором плагинов (расширений для различного функционала). Если мы выбираем стандартную установку, установятся только те плагины, которые сами разработчики протестировали и выбрали. Если мы выберем установку с выбором, соответственно система даст возможность установить не только стандартные, но и другие плагины.
Выбираем стандартную установку и начинается процесс настройки самого Jenkins.
Мы можем видать, что ставится git плагин, LDAP для работы с Active Directory, ssh для взаимодействия по протоколу ssh, расширение E-mail для отправки уведомлений и.т.д
После непродолжительного ожидания, система предлагает создать суперпользователя с правами администратора в системе.
Заполнение не сложное. Если бы мы выбрали другой вариант установки, то система нам предложила бы выбрать самостоятельно нужные плагины.
Примерно вот в такой форме. Форма от версии к версии может отличатся.
По окончанию заполнения формы, попадаем на экран где нам предлагают проверить URL, т.к эти данные будет Jenkins использовать, как переменные среды.
В итоге мы попадаем на главный экран Jenkins. Данный экран – это основной рабочий стол. С помощью плагинов его можно кастомизировать. Так же можно в джобы добавить много разных параметров.
Пользователи очень часто встречаются с ошибкой 32788 в среде виртуализации Hyper-V. Если быть точным, то полная формулировка ошибки следующая:
The application encountered an error while attempting to change the state of %имя_виртуальной_машины%.%имя_виртуальной_машины% failed to change state. The operation cannot be performed while the object is in use with error code 32788
Выглядит это «неприятное» popup окно примерно вот так:
Ошибка появляется, когда пользователь пытается запустить виртуальную машину. Итак, погнали разбираться. Данный гайд подойдет для Hyper-V версий 2012 R2 и 2016.
Краткая матчасть
Ошибка возникает, из за того, что виртуализация это несколько более сложная штука, чем просто создание виртуальных вычислительных машин поверх физического устройства. Внутри каждой есть операционные системы, сетевые адаптеры, виртуальные коммутаторы, устройства для хранения, интерфейсы взаимодействия и другие.
Сам интерфейс Hyper-V – это лишь консоль управления. Устаревшая и неактуальная конфигурация виртуальных машин приводит к возникновению ошибок. В том числе, и ошибке 32788.
Основные причины ошибки 32788
Самые главные причины ошибки 32788, которые мы воспроизводили на опыте:
Конфликт (неточность/неактуальность) конфигурации виртуальной машины;
Изменения виртуального коммутатора (VM switch) на машине;
Исправляем ошибку 32788
Итак, чтобы исправить ошибку, нужно:
Открыть Settings (настройки) виртуальной машины. В списке виртуальных машин, нажмите правой кнопкой мыши на нужную виртуальную машину и выберите Settings;
Откройте настройки сетевого адаптера (Network Adapter Settings). А так же пробегитесь по всем пунктам меню слева (Memory, Processor, IDE Controller и так далее), на предмет обнаружения уведомления с надписью Configuration Error. В нашем примере, виртуальная машина столкнулась с проблемой того, что виртуальный коммутатор (Vswitch), к которому она подключена, более не существует (The network adapter is configured to a switch which no longer exists…)
Вот она, причина ошибки 32788 в нашей случае – устаревшие настройки виртуального коммутатора. Возможно, его кто то удалил, или изменил его имя.
В любом случае, нам нужно исправить это. Создаем новый виртуальный коммутатор (Virtual Switch) типа Internal, для внутреннего использования:
После внесение всех изменений перезагрузите (выполните рестарт) виртуальную машину.