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

Внутри типичного компьютера много устройств, управляемых встроенными в них микроконтроллерами. Эти микроконтроллеры обычно вообще никак не видны операционной системе или, скажем, коду BIOS. Но при этом они оснащены памятью, имеют достаточно высокую производительность и позволяют делать много интересного, чем и привлекают специалистов в области информационной безопасности. Привлекают, надо сказать, очень давно. Особенно многообещающе выглядят векторы атак, связанные с устройствами хранения данных. Причина в том, что код, исполняемый микроконтроллером, оказывается в привилегированном положении: он может изменять данные, например, считываемые с жёсткого диска, но при этом никак не ограничен в правах доступа операционной системой или каким-нибудь другим элементом вычислительной системы. То есть, микроконтроллер имеет своего рода “рутовый доступ”.

Конечно, об этом известно давно. Есть немало практических демонстраций. Например, в одной из них (это 2013 год) изменённый программный код микроконтроллера позволяет подменять данные, считываемые с жёсткого диска, тем самым создавая универсальный инструмент получения неограниченного удалённого доступа к серверу. Вчера про “дополнительное ПО” в контроллерах жёсткого диска сообщили из “Лаборатории Касперского”. Этого, конечно, можно было ожидать. Интересно, что антивирусное ПО обнаружить такую “полезную нагрузку” не может, так как полное сканирование памяти микроконтроллеров потребует специального оборудования.

Санкции, предписанные федеральным правительством штатовским ИТ-компаниям, привязаны к определённым территориям. Не все сервисы, устройства и услуги можно выключить с высокой точностью, основываясь на геопривязке. Но многие – можно. Например:

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

некоторые операционные системы – например, Microsoft Windows ходят за обновлениями на серверы Microsoft, а идентификатор установки этой ОС имеет региональную привязку (по данным от магазинов и компаний-интеграторов). С уверенностью говорить нельзя, но, теоретически, ОС могут быть заблокированы с помощью раздачи некоторого специального обновления, срабатывающего только на некоторой выборке идентификаторов (лицензионных ключей). Естественно, в правильно настроенной коропативной среде такие обновления сами могут быть предварительно заблокированы, но наивно полагать, что такие среды встречаются повсеместно;

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

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

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

Хуже всего, что, в теории, подобные блокировки могут коснуться и промышленного оборудования: современные АСУ (SCADA и т.д.), к сожалению, также не отличаются автономностью, а поэтому могут быть заблокированы дистанционно, по практически официальным каналам управления и обновления.

В общем, есть где развернуться.

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK) и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне .org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

Итак, мы решили получить SOA-запись (это главная запись в любой DNS-зоне) от .org и проверить её. Нет ничего проще: получаем SOA, вместе с ней приходит RRSIG, сгенерированная от ключа 11112, этот ключ есть у нас в списке доверенных, поэтому проверяем подпись – если сходится, то верим данным из SOA-записи. (Аналогично – для А-записей и для прочих.)

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.

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

Самое очевидное – скрытность, тут и обсуждать-то особенно нечего. Плохо спрятанный бэкдор компрометирует саму идею. Хотя, можно придумать случаи, в которых и через вполне заметный бэкдор происходит регулярная утечка информации, потому что пользователям всё равно, ну или они вынуждены пользоваться подозрительным инструментом.

Бэкдор должен обладать свойством “отрицаемости”: то есть, в случае его обнаружения, разработчики должны иметь возможность аргументированно “доказать”, что никакого бэкдора и нет, а это всё “непреднамеренная ошибка”, “особенность протокола” или ещё что-то подобное.

Бэкдор должен быть защищённым от перехвата. Возможность использовать его для организации утечки должна быть доступна только “уполномоченной стороне”. Это свойство очень близко к скрытности, но не является её эквивалентом: например, побочные излучения аппаратуры можно принимать, даже не зная о том, какая именно аппаратура является источником.

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

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

Конечно, большинство практических бэкдоров лишены некоторых из перечисленных выше свойств. Но где-то могут быть и идеальные представители. Просто их не так легко обнаружить.

В Wired публикуют статью о том, что спецслужбы США (АНБ, в основном) не собирают больших справочных баз данных по уязвимостям в ПО, неизвестным широкой общественности. Речь идёт о практике публикации (или, наоборот, сокрытия) информации об уязвимостях, которые находят аналитики АНБ (и других профильных агентств). Если уязвимость сохраняется в секрете, то её можно длительное время использовать для атак на информационные системы. Однако от этой же уязвимости, как пишут, могут пострадать информационные системы США – то есть, лучше бы её опубликовать, чтобы разработчики заткнули дыру. Такая дилемма.

Вообще, можно, конечно, предположить, что таких государственных баз данных нет, но не ясно, как, в таком случае, работают аналитические подразделения АНБ. Ведь если каждый раз, когда уязвимость обнаружена, о ней бы сообщали разработчикам ПО, это повлекло бы за собой утечку информации о том, с чем работает данная служба. Особенно интересной представляется ситуация, когда уязвимость обнаружена в иностранном ПО (или в каком-нибудь иностранном оборудовании). Хотя, конечно, в Штатах такое положение дел встречается не так уж часто.

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

До сих пор нередко встречаются “продвинутые пользователи” персональных компьютеров, старой закалки, которые свой рабочий компьютер не подключают ни к каким вычислительным сетям, а данные переносят на флешках. То есть, к сети компьютер не подключен, “чтобы никто не влез или вирус не пробрался”, но так как некие “конфиденциальные данные” нужно, например, распечатать, они копируются на флешку, с которой пользователь отправляется на другое рабочее место, с целью передачи документа на сетевой принтер.

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

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

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

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

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

В общем, распознавание лиц в режиме онлайн – это весьма горячая тема, которая в ближайшие пару лет наверняка принесёт немало скандалов и неизвестных ранее проблем.

Известно, что параметры бытового электропитания, например, 220 вольт и 50 герц, в реальности далеки от стабильности: в линиях всегда присутствует шум разнообразной природы. Этот шум можно записывать, если подключить к проводам подходящую аппаратуру. Понятно, что ряд характеристик шума будет общим для той или иной большой группы потребителей. Более того, параметры шума будут уникальными для выбранного интервала времени.

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

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

(Вот одна из работ по данной теме.)

(Меня попросили простыми словами объяснить, как работают методы считывания секретных ключей через побочные излучения и наводки, например через измерение электрических параметров ноутбука, как продемонстрировано в недавней работе Genkin, Pipman, Tromer. Думаю, что описание достаточно интересно и для публикации на dxdt.ru, тем более, что в нём, на мой взгляд, есть наблюдения, полезные для понимания деталей работы современных реализаций RSA и принципов разработки криптографического ПО.)

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

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

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

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

Перейдём к конкретному примеру, описанному в исходной работе: получение ключа RSA при помощи измерения электрического потенциала на корпусе (“земле”) ноутбука. (В работе речь идёт также о криптосистеме ElGamal, но принцип атаки совершенно аналогичен, поэтому мы будем рассматривать только случай RSA.) RSA использует операцию возведения в степень, и для шифрования, и для расшифровывания. Напомню, что секретной в RSA является расшифровывающая экспонента, обратная к шифрующей экспоненте. Последняя входит в состав открытого ключа, наряду с модулем (большим числом, задающим конечное множество чисел, в котором осуществляются операции для данного ключа). RSA работает с очень большими числами (2048 бит и более). Арифметические операции над ними, если их осуществлять “в лоб”, занимали бы слишком много времени, даже при работе на самых мощных компьютерах. К счастью, известно большое число оптимизаций, сводящих умножение (возведение в степень) больших целых чисел RSA к некоторому разумному количеству операций. Эти оптимизации всегда являлись проводником для возникновения побочных каналов утечек. Они же используются и в этот раз.

Итак – секретной частью ключа RSA является расшифровывающая экспонента. Это целое число. Достаточно большое. В компьютерной памяти, естественно, оно представлено в двоичном виде. Операции с ним также осуществляются, грубо говоря, побитно – это одна из оптимизаций для быстрого умножения. После того, как исследователи определили, что можно различить исполняемые центральным процессором компьютера серии одних и тех же операций, измеряя потенциал на его корпусе, осталось найти такие зацепки в программном коде, которые позволили бы, на основе этих измерений, различать единицы и нули шифрующей экспоненты. Здесь и кроется основная задумка работы. Зацепки удалось найти в части кода GpuPG, осуществляющей умножение: здесь для 1 и 0 шифрующей экспоненты выбирались разные ветки кода, исполнение которых, при определённых условиях (см. ниже про шифротекст), оставляло разные следы в измеряемом канале утечки.

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

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

Выбрать правильный шифротекст, из-за особенностей реализации RSA, не представляло особого труда: подходит значение m – 1, где m = pq – модуль ключа, который, как известно, равен произведению двух простых чисел p и q. Значение модуля является открытым. (В секрете держится только разложение на p и q. Несмотря на то что, строго говоря, для расшифровывания сообщения нужно знать только расшифровывающую экспоненту, значения p и q сохраняются, чтобы в дальнейшем использовать их для оптимизации умножения при расшифровывании сообщений.)

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

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

И рекомендую почитать исходную работу (PDF).

Пишут, что специальные хакеры (указывают на китайских) в 2011-2012 годах проникли во внутренние сети крупных израильских оружейных компаний и хозяйничали там несколько месяцев, утаскивая, как минимум, важную документацию. Наличие удалённого хакерского доступа в корпоративную сеть, которая наверняка пересекается с сетью разработчиков систем вооружений, наводит на мысли о внедрении закладок в бортовое программное обеспечение, например в ПО головки самонаведения ракеты, или в вычислительные системы командного пункта зенитно-ракетного комплекса. Возможно ли такое?

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

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

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

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

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

Вот здесь, используя один из новых доменов верхнего уровня (.systems), объявляют о том, что раскроют исходные коды (и сопутствующую информацию – см. ниже) микроядра seL4. Главная особенность данного ядра ОС в том, что его реализация прошла через процедуру формального доказательства её соответствия спецификации. То есть, доказано, что в реализации отсутствуют некоторые классы типичных ошибок и уязвимостей. (Пишут, что всё это касается версии ядра для архитектуры ARM, и что seL4 – первое ядро, прошедшее подобную проверку.)

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