dxdt.blog: занимательный интернет-журнал

Update (19/02/2019): реализовал преобразования блока на ассемблере для платформы x86-64/amd64, это даёт прирост производительности в несколько раз – доступна новая версия, использовать лучше её.

Продолжение реализации шифра “Кузнечик” (ГОСТ Р 34.12-2015) на языке Go. Я заменил в предыдущей реализации побайтовые XOR на 64-битные, это дало прирост производительности примерно в семь раз. Кроме того, я довольно существенно изменил код, дописав функции, реализующие операции шифрования/расшифрования с уже развёрнутыми наборами ключей – это необходимо для использования шифра в потоковом режиме.

Собственно, основной задачей было прицепить к “Кузнечику” режим GCM. Дело в том, что реализация работы с отдельными блоками сама по себе ничего не даёт, так как использовать шифр в таком режиме нельзя на практике (ну, разве что в роли генератора псевдослучайных чисел). Режим GCM – современный режим шифрования. Его, например, скорее всего использует ваш браузер, когда получает страницы dxdt.ru. Правда, браузер использует GCM в связке с AES. Но GCM совместим с любым блочным шифром подходящей разрядности. “Кузнечик” имеет разрядность блока 128 бит, так что он как раз подходит: достаточно взять реализацию GCM и подключить к ней “Кузнечик” в качестве шифра. В Go есть штатная реализация GCM. Поэтому мне оставалось только дописать интерфейсы к модулю “Кузнечика”, чтобы он оказался совместим со штатной реализацией GCM. Что получилось:

• новая реализация “Кузнечика” на Go – kuznec.go;
• достаточно детальный пример использования “Кузнечика”, вместе с небольшим тестом производительности – test_grasshoopper.go;
• всё в одном архиве.

Небольшая справка: GCM – Galois/Counter Mode – режим счётчика с аутентификацией Галуа: это режим аутентифицированного шифрования, который, к тому же, поддерживает аутентификацию дополнительных данных (передаются в открытом виде). В англоязычной литературе это называется AEAD – Authenticated Encryption with Associated Data. В ГОСТовой криптографии такого режима как раз не хватает. Аутентифицированное шифрование позволяет обнаружить изменения сообщения до его расшифрования, для этого сообщение снабжается специальным кодом аутентификации (в русскоязычной традиции также называется имитовставкой). GCM позволяет защитить кодом аутентификации не только шифрованную часть сообщения, но и произвольные прикреплённые данные – это полезно, потому что в этих данных может быть записан, например, адрес получателя или другая открытая информация, которую, вместе с тем, требуется защитить от искажений/подмены. Я планирую как-нибудь написать в подробностях про шифры и режимы шифрования, в том числе, про GCM, скорее всего, в рамках дополнения к описанию TLS.

(Отдельно замечу, что данная реализация “Кузнечика” является лишь примером возможного использования данного шифра. Зато в режиме GCM можно, так сказать, полноценно шифровать большие файлы.)

Англоязычное пояснение:

This is the next implementation of GOST R 34.12-2015 Kuznyechik cipher in Golang. With optimized XOR and some other improvements the performance is about seven times better. Also it is now possible to use GOST R 34.12 package with crypto/cipher, particularly in GCM operation mode. New code has new name – kuznec.go. More comments – in Go source code for Kuznyechik (and see links in Russian text above).

Update (20/02/19): реализовал преобразования блока на ассемблере для платформы x86-64/amd64, это даёт прирост производительности в несколько раз – доступна новая версия, использовать лучше её.

“Кузнечик” это новый российский блочный шифр, в прошлом году стандартизованный ГОСТ Р 34.12-2015. Шифр работает с блоками в 128 бит, ключ имеет длину 256 бит. (Текущим аналогом является шифр AES.) На досуге я реализовал “Кузнечик” на языке Go. Это, конечно, реализация пока далёкая от оптимальной и строгой (в смысле “криптокода”). Например, работа с блоками написана “побайтово”, не используются другие достаточно очевидные оптимизации и штатные языковые конструкции Go (я пока не очень освоился с данным языком). Так сказать, альфа-версия. Приветствуются комментарии, поправки. Возможно, имеет смысл развивать дальше.

Исходники выкладываю на dxdt.ru:

исходный код модуля grasshopper (Kuznyechik, GOST R 34.12-2015);
небольшая программа для проверки работоспособности (реализован стандартный вектор проверки и один дополнительный);
оба файла в .tar.gz.

(Внутри исходников комментарии на английском.)

Некоторые технические пояснения. Работу данного шифра можно ускорить, если использовать достаточно большие таблицы с предвычисленными преобразованиями. Именно этот вариант и реализован. Впрочем, функций Decrypt – две. Одна версия использует все таблицы, вторая – только одну, в которой содержатся предвычисленные значения линейного преобразования. Сами таблицы не содержатся в исходном коде, а вычисляются вызовом функции инициализации. В Go есть штатная библиотека, реализующая режим аутентифицированного шифрования GCM. Обычно этот режим используют в связке с AES, но годится и другой шифр подходящей разрядности. Соответственно, есть идея реализовать связку Kuznyechik-GCM, которая уже является практически полезным инструментом (update: реализовал режим GCM).

(Напомню, в скобках, что сам по себе блочный шифр, реализующий зашифрование/расшифрование, является лишь низкоуровневым элементом криптосистемы – применять его в отдельности, наивным образом, нельзя. Нужен правильный режим использования. Сейчас правильным режимом считается тот или иной режим аутентифицированного шифрования, превращающий блочный шифр в потоковый и снабжающий данные кодом аутентификации имитовставкой.)

Англоязычное пояснение:

This post describes GOST R 34.12-2015 Kuznyechik reference implementation in Golang. More comments – in Go source code for Kuznyechik. There is a different version available.

GAO (это такой контролирующий правительственный орган в США) опубликовали отчёт, касающийся перспектив обновления государственных информационных систем. В нём, в частности, сказано, что в минобороны США до сих пор используют 8-дюймовые дискеты, в системе, связанной с планированием и управлением ракетно-ядерными силами. Тему дискет (которые сейчас принято считать 3D-принтерными версиями иконки Save из интерфейсов офисных программ), конечно, подхватили СМИ. При этом некоторые схожие системы в других странах (в США, впрочем, наверняка тоже) до сих пор используют перфокарты. И в этом нет ничего особо страшного. Строго говоря, большая дискета с низкой плотностью записи, при правильном использовании, достаточно надёжна. Но перфокарта, несомненно, лучше, потому что хранит данные чисто механическим способом.

Кстати, в GAO не упустили повода и заметили, что “современный флеш-накопитель по объёму хранимых данных эквивалентен более чем 3,2 млн дискет”. Сложно было бы придумать более банальное пояснение. Ну, ясное дело, если вы передаёте полётное задание для МБР на подводную лодку, очень важно упаковать его в какую-нибудь новомодную софтверную обёртку из встроенных процедур и свернуть вместе с NoSQL-СУБД и прочим ПО в контейнер Docker, который как раз влезет на флешку, если, конечно, удастся грамотно подобрать окружение. (Да, естественно, в отчёте названа и основная актуальная проблема дискет – их “сейчас сложно достать”.) Если вы военная система и передаёте примерно тысячу октетов в качестве полётного задания, то использовать вместо дискеты флешку, только потому, что это модно среди пользователей “офисных пакетов”, несколько неразумно. Я бы вернулся к перфокарте, но реализованной на современном уровне.

Другой неплохой пример “отсталых технологий” – линия голосовой связи на двух древних аппаратах ТА-57. Это старые, самодостаточные аппараты, оснащённые операционной системой типа “Ручку покрутил”. Соединяют их между собой проводами. В сравнении с современным смартфоном, ТА-57 имеет целый ряд преимуществ. Главное из них в том, что восстановить линию, если что, можно даже не при помощи пассатиж и монтажного запаса кабеля, но и лишь задействовав гвоздь и куски проводов с ближайшей, извините, свалки. Восстановить же с похожим инвентарём работу базовой станции GSM – получается, так сказать, далеко не во всех случаях (проверено, некоторые пробовали). А чинить смартфон в ситуации, когда может потребоваться ТА-57, – вообще нет смысла.

Под двухфакторной аутентификацией подразумевают использование некоторого дополнительного источника аутентификационной информации. Например, помимо имени пользователя и пароля, требуется указать некий код, получаемый при помощи специального аппаратного “токена”, по схеме “нажал на кнопку – получил код” (кстати, едва ли не единственная более или менее полезная схема реализации). Про двухфакторную аутентификацию сейчас стало очень модно говорить. Особенно занимательно звучат её упоминания в контексте взлома учётных записей того или иного сервиса: “аутентификация двухфакторная, но всё равно взломали!”

В реальности, двухфакторные схемы совсем не являются панацеей. Более того, вовсе не обязательно, что использование “второго фактора” как-то повышает уровень безопасности. Например, типичный сценарий использования двухфакторной аутентификации сводится к тому, что устройство-источник “дополнительного фактора” является виртуальным – это просто программа, генерирующая коды. Программа исполняется на том же самом компьютере, который используется для доступа к защищаемой учётной записи. А это означает, что в случае наличия троянской программы для кражи обычного пароля, атакующая сторона получит и доступ ко “второму фактору”, так как его генератор работает там, куда уже получен доступ через троянскую программу. (Думаю, понятно, что последняя содержит кейлогер и другие стандартные инструменты.) Или, скажем, для доступа к сервису используется тот же смартфон, который служит элементом двухфакторной аутентификации (вплоть до приёма SMS – но это отдельная история, см. ниже).

Предположим, что пользователь применяет для работы с некоторым сервисом приложение (программу-клиент), предлагающее ввести пару логин/пароль и дополнительный код. Нередко, протокол, реализующий проверку данного кода, позволяет имитировать сессию. В локальном случае – пользователю показывается имитатор приложения, где он указывает все “факторы”. Удалённая схема работает иначе: перехватывается начало сессии, внешним узлом имитируется работа авторизационного сервера (делается, например, при помощи подмены DNS силами взломанного роутера), а уже этот узел собирает валидный набор параметров аутентификации (их предъявляет приложение); в чуть более продвинутом случае, когда используется схема “запрос-ответ”, перехватывающий узел проксирует и запросы, и ответы. (Да, очевидно, что схема сработает только в случае недостаточно защищённого канала.)

Идея схемы “запрос-ответ” во многих случаях переносится на такой транспорт, как сеть GSM: код, который нужно ввести для успешной аутентификации, высылается в SMS на некоторый номер телефона. В данном случае степень защищённости сводится к уровню безопасности сети связи GSM (и смартфона, принимающего SMS). Почему? Потому что код из SMS обеспечивает защиту только в том случае, когда атакующая сторона уже узнала пароль. То есть, если пароль достаточно хорошо защищён, SMS не требуется. Соответственно, на практике, “стойкость” такой двухфакторной системы равна “стойкости” защиты сети GSM (включая административные особенности, вроде перевыпуска SIM-карты; причём, из-за фундаментального конфликта схем использования, поделать с этим ничего нельзя).

Двухфакторная аутентификация – всегда замыкается на одного пользователя (естественно, за исключением редчайших схем, вроде доступа к банковскому хранилищу). В случае целевой атаки это означает, что увеличивается число направлений, доступных для атакующего: все элементы схемы аутентификации находятся рядом с пользователем, фактически, в одном пространстве атаки. Например, упомянутая выше программа-генератор кодов доступа, которая исполняется на том же самом компьютере, представляет собой дополнительный вектор атаки: уязвимость в данной программе (а она нередко находится в контексте с высокими привилегиями, типа, “для безопасности”) может послужить неплохой точкой входа для троянского кода, который уже и пароли прочитает, и коды получит, и аутентификацию выполнит в прозрачном для пользователя режиме.

Исследователи реализовали программу, которая распространяется между промышленными микроконтроллерами Siemens SIMATIC S7-1200 – есть публикация, описывающая принцип работы червя. Схема, отчасти, напоминает старые времена, когда небольшие вирусы распространялись между ПК, под управлением MS-DOS – правда, для появления действительно массовых вариантов потребовалось внедрение Windows, тогда появились решения, распространяющиеся без малейшего участия пользователя, просто передавая пакеты по сети. Собственно, описанный в статье червь для микроконтроллеров именно так и действует. А главная особенность в том, что для распространения не требуется ПК.

Предполагается, что микроконтроллер подключен к внутренней сети посредством Ethernet (такой порт имеется): программа сканирует IP-адресное пространство, пытаясь установить соединение TCP по известному номеру порта, который соответствует проприетарному протоколу Siemens. Если удалось установить соединение, то червь проверяет, не заражён ли уже найденный контроллер, а если нет, то копирует туда свой код. Для передачи кода используется протокол Siemens, предназначенный для управления контроллерами. Дело в том, что архитектура предполагает возможность удалённого обновления микропрограмм. В штатном режиме обновление проводит центральный управляющий узел, однако никакой аутентификации не предусмотрено (приходится признать, что это обычная ситуация), поэтому таким узлом может прикинуться всякий другой, в том числе, инфицированный червём микроконтроллер.

Авторы работы пишут, что во внутреннюю сеть червь может быть занесён в составе перепрошитого микроконтроллера. Понятно, что злоумышленник может и просто подключиться к сети, чтобы загрузить туда червя любым удобным способом. Архитектура Siemens содержит некоторые механизмы защиты, которые, впрочем, направлены не на предотвращение заражения, а на защиту “интеллектуальной собственности”, поэтому эффективным оказывается лишь режим, запрещающий запись микропрограмм на уровне контроллера (используется пароль).

Занятно, что также предусмотрен режим защиты микропрограммы от считывания и модификации, но он, во-первых, реализован на уровне управляющего узла – то есть, сам микроконтроллер манипуляции не ограничивает, можно работать напрямую, минуя управляющий узел, – во-вторых, ключ шифрования (используется AES) легко восстанавливается из доступных данных (это всего лишь часть значения хеш-функции от пароля).

В общем, поле промышленных систем (АСУ ТП) – непаханое, и тут отлично подходят методы атак, которым 15-20 лет.

В бета-версии “Яндекс.Браузера” появилась поддержка DNSCrypt. Посмотрим, как она работает. Для активации – нужно включить опцию “Всегда использовать … DNSCrypt” в настройках браузера (опция, похоже, доступна только в версии под Windows). После этого браузер начинает использовать сервер “Яндекс.DNS”, с IP (в моём случае) 77.88.8.78, отправляя запросы DNSCrypt по UDP на номер порта 15353. Сессия DNSCrypt, согласно протоколу, начинается с отправки пакета, содержащего в открытом виде имя сервера и версию протокола: 2.dnscypt-cert.browser.yandex.net. Данный запрос необходим для получения сертификата сервера и генерации криптографического контекста, который далее будет использоваться клиентом и сервером для шифрования запросов/ответов. Вообще, протокол DNSCrypt не ставит задачи сокрытия самого факта использования DNSCrypt, поэтому может быть легко блокирован с использованием системы DPI. Трафик DNSCrypt “Яндекс.Браузера”:

Но самое занимательное, что если просто заблокировать доступ к 77.88.8.78, то бета-версия браузера в прозрачном режиме (молча, без каких-либо уведомлений) переходит на штатный системный резолвер, игнорируя опцию DNSCrypt в настройках (“Яндекс” про это прямо пишет). Вообще говоря, такое положение дел позволяет провайдеру, желающему перехватывать DNS-запросы, заблокировать доступ к “Яндекс.DNS” и продолжить вмешиваться в трафик. То же самое может сделать и “взломанный домашний роутер”. То есть, в заявленной “модели угроз”, такое решение по внедрению DNSCrypt с защитой не справляется никак: “злой провайдер” последней мили сможет легко и незаметно отключить использование DNSCrypt. (Отмечу, что “Яндекс” собирается с этим побороться: прямо запретив такой “даунгрейд” протокола.)

Естественно, в реализации DNSCrypt могут быть уязвимости, начиная от некорректной аутентификации сервера (протокол предусматривает двухстороннюю аутентификацию, вопрос в том, как она реализована в браузере “Яндекса”) и до различных дефектов и утечек, связанных с генерацией и использованием ключей.

Лет шесть-восемь назад я несколько раз рассказывал про то, что комплексы ПВО (как пример) являются системами, работающими с данными, которые поступают извне, поэтому возможно активировать аппаратные закладки дистанционно и разными способами, несмотря на то, что радиоэлектронная система комплекса “не подключена к внешним сетям”. Сейчас похожая ситуация складывается с кибербезопасностью автоматических систем управления технологическими процессами (АСУ ТП). (Да, не так много лет прошло, а тема ИБ добралась и до заводских конвейеров). Здесь есть интересные направления для атак, которые совсем не применимы для “офисных” систем. Одно из таких направлений: различные датчики.

Современные датчики бывают довольно продвинутыми, в плане взаимодействия со считывающими устройствами. Например, цифровые датчики температуры не только измеряют её значение, но и передают его в цифровом виде по линии связи, которая разделяется между многими датчиками – общая шина (есть несколько стандартных интерфейсов, например, 1-Wire). Датчик содержит схему кодирования, умеет видеть свой адрес на общей шине и так далее. Центральное устройство, – нередко, это микроконтроллер, – принимающее информацию от датчиков, полагает, что эта информация будет приходить в заранее определённом формате, и соответственно интерпретирует считываемые с линии цифровые данные. Получается неплохой вход в информационную систему. Понятно, что вместо датчика к линии можно подключить устройство злоумышленника, которое передаст не температуру, а иной код. На первый взгляд, инъекция кода через шину датчиков кажется надуманной. В этом и кроется причина того, что промышленные системы редко защищены по этому направлению: они просто считывают данные и обрабатывают их как доверенные.

Интересно, что никакой там “офисный” антивирус, установленный на управляющем ПК, тут никак не поможет: он просто не видит, что происходит на уровне телеметрической аппаратуры (это если оставить за скобками другие причины, по которым наличие антивирусного ПО – решение довольно сомнительное для АСУ ТП). При этом передача специально подготовленных данных, которые после обработки микроконтроллером и, например, загрузки в БД, превратятся в управляющую команду – вполне реальна.

Особенно богаты на уязвимости беспроводные системы сбора информации: в случае с проводами – злоумышленник ещё должен добраться до провода, подключиться к нему (что, впрочем, не так уж невероятно, если речь идёт о стратегически важных объектах); радиообмен, обычно осуществляемый в открытом виде без аутентификации, упрощает задачу – данные, в рамках атаки, можно транслировать со значительного расстояния, вплоть до передачи с борта самолёта. Дело в том, что многие реализации промышленных протоколов опроса датчиков никак не аутентифицируют ответы. Даже если датчик должен штатно отвечать после передачи в эфир запроса, всегда можно ответить быстрее (да, в особо “сложных” случаях придётся поставить помеху, подавив ответ настоящего датчика, но все эти методы хорошо отработаны ещё на базе WiFi).

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

Шумная история: после обновления iOS, некоторые аппараты iPhone, которые ремонтировались в неавторизованных мастерских, оказались нерабочими (вроде бы, причина – замена сенсора-считывателя отпечатка пальца). Есть множество историй, в которых “выкатка” обновления ПО убивает то или иное устройство. Но в этот раз опять вспомнили о том, что системное программное обеспечение используется и при управлении различными производствами (набравшая наконец популярность тема безопасности АСУ ТП). А раз “внешний” владелец ПО может отключить iPhone, то почему бы не проделать то же самое и с промышленными системами? Про станки, которые дистанционно получают обновления, а также могут быть дистанционно заблокированы разработчиком, если, например, не продлён срок договора обслуживания, – давно известно. Но ещё старше предлагаемое решение: мол, давайте отключим станки и оборудование от Интернета (а программное обеспечение, стало быть, всё равно оставим без изменений), чтобы обезопасить систему управления от отключения извне. В современной ситуации – неправильное решение, и очень наивное.

Зловред Stuxnet, портивший иранские центрифуги на урановом производстве, был занесён в промышленную сеть на “флешке”. Реальность информационной безопасности на производствах, в типичных корпоративных сетях, такова, что если сеть вообще работает, то сейчас для проведения атаки не так уж и важно, подключена она к Интернету или нет. Главное, чтобы компьютеры были соединены между собой, а точка проникновения через наивный “воздушный зазор” (air gap) – найдётся. На практике, из-за человеческого фактора, отсутствие подключения к Интернету и массовое перемещение “флешек” – делают ситуацию хуже, потому что для атаки со стороны USB системы гораздо более уязвимы, чем для атаки из Интернета. (Интернет, кстати – всё равно всегда находится рядом, буквально в одном “хопе”: будь то смартфон или “нелегально” пронесённый 4G-модем, который подключен к компьютеру на рабочем месте. Поделать с этим ничего нельзя, так как отказываться от глобальной Сети, мягко говоря, невыгодно в стратегическом смысле.)

Конечно, не следует делать вывод, что нужно все производственные системы подключить напрямую к Сети. Нет, подключать не нужно. Но в современной ситуации рассчитывать на то, что отсутствие такого подключения как-то защищает “чужую” систему от отключения в критической ситуации – наивно. От легитимного отключения, реализованного банально – да, защитит. Но уже чуть более продвинутое решение, подразумевающее закладку в оборудовании, срабатывающую по времени отсутствия обновлений, вопрос с таким отключением полностью снимает. Кроме того, если говорить о промышленных системах, там передача сигналов возможна иными методами. Если аппаратура, техпроцесс, или управляющее программное обеспечение, хотя бы один из этих элементов – что-то вроде чёрного ящика для тех, кто оборудование использует (а это, обычно, так, к сожалению), то “отключающая закладка” может быть активирована при помощи сигнала, полученного через тот или иной датчик, или, если хотите, даже через изменение химического состава сырья. Или производство останавливается из-за того, что смартфон одного из рабочих “пропищал” своим динамиком кодовую последовательность на высоких частотах, её принял ультразвуковой дальномер, измеряющий уровень масла в котле-смесителе, принял – и просигналил в центральную автоматическую систему управления, которая быстренько сломала весь цех и сама вырубилась (на всякий случай, вместе с телефонией и электричеством). Кажется фантастикой. Но это только кажется, да и казаться будет не долго: потому что к популярной теме “кибербезопасности” АСУ ТП подходят с навыками защиты офисного “домена Windows”, а с промышленными системами ситуация сложнее.

Кстати, что касается Windows XP, которая, якобы, “управляет британскими подводными лодками с ядерным оружием”: возможно, эта система и работает на каких-то компьютерах, находящихся на борту, но вряд ли чем-то на лодке управляет. Дело в том, что Windows XP – не является системой реального времени: с ней всегда были проблемы при попытках управления тем или иным оборудованием. Соответственно, встроенные системы используют другие ОС, обычно, это UNIX-подобные (из-за POSIX, но это детали) ОС реального времени.

Вообще, если речь идёт о системах из 90-х годов прошлого века (это означает, что разрабатывались-то они в конце 80-х), можно было бы поверить, что на борту есть управляющие вычислительные машины, работающие под MS-DOS. Это маловероятно, но такое можно представить, потому что под MS-DOS приложения реального времени работают хорошо, мне, в 90-х, приходилось такие видеть лично. Но XP – это что-то журналисты напутали (особенно, если учитывать, что система выпущена в 2001).

Появился новый робот, быстро собирающий кубик Рубика – он справляется примерно за секунду (по ссылке с картинки – видео на Youtube.com):

Конкретно это решение можно, конечно, покритиковать: там четыре камеры; нужен специально подготовленный кубик (насадки на валах электродвигателей входят в механическое зацепление с центральными элементами сторон кубика); кубик устанавливается в заранее заданном положении (манипуляторы размечены по цветам) и так далее, и тому подобное. Однако интереснее подумать, насколько вообще можно улучшить результат. Вычислительные мощности доступны, поэтому механическая составляющая робота оказывается важным фактором, устанавливающим границы.

Если я не путаю, то сейчас известно, что из любой конфигурации кубик (3×3) собирается не более, чем за 26 ходов, если ходом называется поворот грани на 90 градусов. При этом большинство конфигураций лежат на два-три хода ближе к собранному кубику. Для оценки точное число ходов не так важно. Примем, что типичная сложная конфигурация – 25 ходов. То есть, если поворачивать грань за 10 миллисекунд на 90 градусов, то с преобразованиями конфигурации можно уложиться в 250 мс (плюс затраты на “переключение” граней – но не будем их учитывать). 10 мс – это 9000 градусов или 25 оборотов в секунду. Сама по себе, скорость вращения не очень большая, добротный кубик её наверняка выдержит. Заметные потери времени при “миллисекундном разрешении” будут связаны с разгоном грани – отсюда и идеи с механическим зацеплением. Для немодифицированного кубика быстрый разгон при начале вращения грани составит серьёзную техническую проблему.

Работа робота сводится к определению начальной конфигурации кубика, вычислению оптимального (или близкого к оптимальному) пути из этой конфигурации к собранному кубику, выполнению ходов. Интересно, что оптимальный путь здесь не обязательно кратчайший. Дело в том, что оптимизировать нужно с учётом исполнительного механизма, а он может какие-то ходы выполнять быстрее, а какие-то – медленнее. Например, очевидно, что все повороты должны осуществляться в одну сторону, что некоторые ходы поддаются механическому “распараллеливанию”, а некоторые – нет, и так далее. Изображение кубика требуется получить только один раз, для определения начальной позиции. Причём это изображение может быть низкого разрешения и известной геометрии, так что сколь-нибудь заметного времени на передачу и распознавание не потребуется. Основное вычислительное время – поиск оптимального пути сборки. После того, как получен список ходов – он отправляется в контроллер механизма, который максимально быстро выполняет их, передавая команды исполнительным механизмам. Логично использовать простейший контроллер, а максимум вычислений проводить на управляющем компьютере: результатом работы программы будет являться набор команд на поворот валов электродвигателей, который и передаётся в контроллер (алгоритм выполнения команд должен учитывать параллельное выполнение, так что контроллеру потребуется память и логика, позволяющая одновременно управлять несколькими двигателями).

В общем, тема эта весьма интересная, а особенное техническое развитие она получает после преодоления секундного барьера. (Человеческий рекорд, кстати, чуть менее 5 секунд.)

Сейчас в СМИ очередная волна сравнения различных программных систем по числу обнаруженных уязвимостей. При этом во многих публикациях системы, с меньшим числом обнаруженных уязвимостей называют “более безопасными”, сравнивая их с теми системами, где уязвимостей нашли больше. Однако это неправильно. Такой показатель, как число обнаруженных за некоторый промежуток времени уязвимостей – очень слабо связан с реальной безопасностью использования той или иной системы, даже в случае, если речь идёт о ситуации “при прочих равных”, например, когда сравнивают два распространённых браузера. Число обнаруженных уязвимостей может, разве что, косвенно свидетельствовать о том, какая система более популярна у исследователей. (Это если опустить тот факт, что корректное определение понятия “безопасности” вообще весьма сложно для программного продукта.)

Почему это так? Прежде всего потому, что процесс обнаружения уязвимостей – нестабильный, а сами уязвимости – весьма различны по своему влиянию на степень безопасности использования программной системы. Более того, у разных разработчиков – разные методики и планы реагирования на обнаружение уязвимости. А также – не существует универсального “закона сохранения уязвимостей”. Другими словами: то, что в браузере “Имярек” обнаружили лишь десять уязвимостей, приводящих к отказу в работе, не означает, что в этом браузере нет ещё одной, но уже позволяющей удалённо выполнить произвольный код. А то, что в операционной системе “Имярек-2” обнаружили тысячу уязвимостей, скорее всего никак не повлияло на наличие или отсутствие уязвимостей в другой, не менее распространённой, операционной системе, в которой уязвимостей нашли пока что только сотню. (Хотя, в последнем случае можно предположить, что разработчики второй системы чему-то научились на опыте авторов первой, да и залатали дыры заранее; но, к сожалению, практика показывает, что это скорее фантастика, чем реальность.)