ЗАЩИТА АППЛЕТОВ ОТ АНАЛИЗА СКРЫТЫХ КАНАЛОВ

Изобретение относится к способам защиты апплетов от анализа скрытых каналов, а также к устройству, в котором применяют такие способы защиты.

Апплетом называют любую программу, исполняемую виртуальной машиной. Например, апплетом называют программу, составленную на языке Java-Card и предназначенную для исполнения виртуальной машиной JVM смарт-карты. По аналогии говорят об апплете NET или об апплете Multos для программ, разработанных в среде .NET для смарт-карт (соответственно в среде Multos). Команды, включенные в апплет, часто называют опкодами от "operation code" в контексте Java-Card.

Виртуальная машина является системой, которая может исполнять апплет, записанный в виде последовательности команд, и которая во время исполнения апплета переводит каждую команду в элементарную операцию или в последовательность элементарных операций и исполняет эту(эти) элементарную(ые) операцию(и). Виртуальная машина позволяет изолировать интерфейс, при помощи которого записывают или передают программу, от платформы, которая осуществляет элементарные операции. Примерами виртуальных машин являются, в частности, машины JVM (Java Virtual Machine) или различные варианты CLI (Common Language Infrastructure), такие как CLR (Common Language Runtime) для языка C# (среда .NET). Часто виртуальные машины являются чисто программными системами. В этом случае они позволяют исполнять один и тот же апплет на любых платформах, существенно отличающихся друг от друга, при условии, что существует отдельная виртуальная машина, предназначенная для каждой из этих платформ. Вместе с тем можно также использовать аппаратные виртуальные машины (например, соответствующую электронную схему) или виртуальные машины, объединяющие в себе программную часть и аппаратную часть.

Обратной инженерией апплета называют деятельность, целью которой является достижение понимания, каким образом был разработан апплет, чтобы скопировать, изменить или присвоить апплет, чаще всего без согласия на то со стороны авторов и/или владельцев.

Анализ скрытых каналов является анализом, основанным на данных, получаемых в результате физического использования электронного устройства. Этими данными часто являются изменения некоторых физических величин, происходящие при исполнении программы в электронном устройстве. Этими физическими величинами (называемыми «скрытыми каналами») могут быть, в частности, потребление электроэнергии устройством или электромагнитное поле, создаваемое устройством, и они позволяют различать исполняемые задачи в зависимости от необходимого для них электрического потребления или от электромагнитного излучения, возникающего в процессе их исполнения. Можно также измерять исходящие вибрации (некоторые компоненты могут вибрировать, причем по-разному в зависимости от того, что они делают) или колебания температуры, или время, затраченное на исполнение конкретной задачи ("timing attacks"), и т.д.

Элементарный анализ может представлять собой простую идентификацию данной характеризации в зависимости от данного измерения на соответствующем электронном устройстве. Это относится, например, к так называемым атакам SPA (Simple Power Analysis). Более сложные виды анализа могут опираться на статистические исследования на основе большого числа измерений (это относится, например, к атакам DPA от Differential Power Analysis и, в частности, к атакам HODPA от High Order DPA).

В контексте Java-Card часто стараются держать в секрете последовательности команд, содержащиеся в апплетах, чтобы не допустить изменения этих команд с целью хищения апплета или изменения результата, получаемого во время исполнения апплета.

Однако иногда можно выявить последовательность команд, составляющих программу, путем анализа скрытых каналов, как описано, в частности, в публикации Dennis Vermoen, "Reverse engineering of Java Card applets using power analysis", MSc Thesis, Delft Technology University (performed in Riscure), 2006. Это предопределяет потенциально серьезную уязвимость апплетов Java-card. Анализ скрытых каналов был также применен имеющими на это разрешение организациями (например, Information Evaluation Facility - ITSEF) для оценки защита карт Java, как описано в публикации Serge Chaumette and Damien Sauveron "An efficient and simple way to test the security of Java Cards", in Proceedings of 3rd International Workshop on Security in Information Systems (WOSIS 2005), Компании «Сажем Секюрите» принадлежит патент на изобретение «Защита программы, интерпретируемой виртуальной машиной» номер FR2903508B1, в котором предложено маскировать команды для их зашиты от анализа этого типа.

Чтобы раскрыть команды апплета, хакер может, например, действовать в два этапа.

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

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

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

C1 - легкое получение правильных моделей,

C2 - затрудненное получение правильных моделей,

C3 - невозможность получения моделей,

C4 - получение ложных моделей.

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

Ситуация C2 может произойти, в частности, если установлены некоторые аппаратные или программные средства защиты. Решение, использующее детерминированный шум и предложенное в патенте FR 2903508 B1, позволяет затруднить извлечение моделей. Меры для десинхронизации сигналов (например: джиттер, разделение во времени …) могут помешать получению моделей, но вместе с тем их можно все же выявить, благодаря технологиям обработки сигнала. С точки зрения эффективности решение по FR 2903508 B1 является относительно дорогим. Кроме того, если детерминированный шум генерирован неправильно (то есть, если он не приводит к сигнатурам, в значительной степени похожим на сигнатуры, обычно генерируемые во время исполнения рассматриваемой команды), хакер может успешно выделить необработанные сигналы.

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

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

В основном можно считать, что возможности C3 и C4 не могут привести к этапу детектирования. Что касается возможностей C1 и C2, то они, как правило, позволяют производить детектирование команд на втором этапе, на котором можно рассмотреть две ситуации:

D1 - модели, легко детектируемые во время исполнения,

D2 - трудно детектируемые модели.

Ситуация, в которой невозможно детектировать модели, как правило, является результатом ситуации C3 и поэтому не рассматривается.

На фиг.1 представлены пять сценариев, которые могут произойти при обратной инженерии апплета путем анализа скрытых каналов и которые обозначены S1, S2, S3, S4 и S5. Как правило, комбинация C2-D1 встречается очень редко. Действительно, если хакеру трудно создавать характеризующие апплеты, чтобы наблюдать атакуемое устройство и определять модели, то вполне вероятно, что последующая фаза детектирования тоже будет затруднена, учитывая ненадежность качества моделей.

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

В документе WO 02/50641 (Nicolas Giraud et al.) раскрыт способ защиты исполнения оператора (в частности, оператора «исключающее ИЛИ»), являющегося частью набора арифметических команд микропроцессора. Этот способ состоит в замене исполнения одного и того же оператора исполнением одной из нескольких возможных последовательностей операций, при этом различные последовательности функционально идентичны с оператором. Однако этот способ защищает оператор, не делая различия относительно контекста использования этого оператора. С другой стороны, он не предусмотрен для специфической защиты электронного устройства, оснащенного виртуальной машиной (электронные устройства этого типа даже не упоминаются).

Вместе с тем, эти защитные меры не являются идеальными.

Изобретение призвано улучшить ситуацию.

Одним из объектов изобретения является электронное устройство, оснащенное виртуальной машиной для исполнения апплета, при этом виртуальная машина выполнена с возможностью распознавания команд апплета и исполнения кода, соответствующего каждой команде. Электронным устройством является, например, смарт-карта (SIM-карта, банковская карта, медицинская карта и т.д.), электронный документ удостоверения личности (электронный паспорт, электронное удостоверение личности, электронная виза и т.д.), ключ USB, электронный токен и т.д. Виртуальная машина содержит модуль ассоциирования, выполненный с возможностью связывать с одной командой несколько разных, но функционально идентичных кодов. Таким образом, виртуальная машина может иметь несколько возможностей исполнения одной и той же команды. Можно защитить несколько команд, при этом каждая из них связана с несколькими разными, но функционально идентичными кодами. Определение наборов кодов, предназначенных для ассоциирования с каждой командой, можно осуществить заранее (например, во время разработки устройства), и в этом случае модулю ассоциирования достаточно запомнить список заранее определенных кодов, связанных с каждой рассматриваемой командой. Виртуальная машина содержит также модуль выбора, выполненный с возможностью случайного выбора предназначенного для исполнения кода для рассматриваемой команды. Под «случайным» следует понимать то, что для системы, внешней по отношению к устройству, невозможно легко выявлять детерминистические свойства, которые позволяли бы предсказывать результаты будущего выбора в зависимости от результатов прошлого выбора. Выбор можно осуществлять, например, при помощи так называемого генератора «псевдослучайных чисел», такого как линейный конгруэнтный генератор, который может быть программным или аппаратным средством. Ряд случайных чисел, генерируемый таким генератором, является детерминированным, но с длинным периодом и опирается на секрет, который не известен внешней среде. Модуль ассоциирования и модуль селекции являются, например, программными модулями, исполняемыми процессором устройства, или модулями жесткой логики (например, для виртуальной машины, реализованной при помощи соответствующего электронного компонента).

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

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

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

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

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

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

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

Согласно варианту выполнения, пятью наиболее частыми командами являются команды sload, sconst_0, baload, getfield_a_this, sstore, и можно изменять только эти пять команд и даже любую подгруппу из этих пяти команд.

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

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

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

Согласно варианту выполнения, различные коды, связанные с командой, различаются по времени их исполнения устройством.

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

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

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

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

Другие аспекты, задачи и преимущества изобретения будут более очевидны из описания одного из вариантов его выполнения со ссылками на прилагаемые чертежи, на которых:

Фиг.1 иллюстрирует различные сценарии обратной инженерии апплета посредством анализа скрытых каналов.

Фиг.2 - диаграмма, иллюстрирующая осуществление защиты апплета согласно варианту выполнения изобретения.

Согласно варианту выполнения, защита программы, интерпретируемой виртуальной машиной, от обратной инженерии, использующей анализ скрытых каналов (называемый "side-channel analysis" на английском языке), основана на использовании альтернативных моделей, позволяющих затруднить фазы характеризации и детектирования.

Таким образом, команда (опкод) может соответствовать нескольким разным кодам, то есть нескольким разным моделям.

Кроме того, одна модель может соответствовать нескольким разным командам. Например, как правило, операция сложения (ADD) является очень близкой к операции вычитания (SUB). ADD и SUB можно кодировать таким образом, чтобы их сигнатуры были идентичными или очень близкими. Например, можно предусмотреть осуществление сложения ADD, которое в качестве параметров использует два операнда Op1 и Op2, следующим образом:

Считывание Op1

Считывание Op2

X = Дополнение Op2

Вычисление Op1+Op2

Запись Результата в память

В данном случае видно, что вычисляют дополнение второго параметра операции, но результат этого вычисления не используют. Можно осуществить соответствующую операцию SUB следующим образом:

Считывание Op1

Считывание Op2

X = Дополнение Op2

Вычисление Op1+X

Запись Результата в память

Отмечается, что эта операция SUB включает в себя точно такие же стадии, что и операция ADD, но только использует в качестве параметра в строке 4 дополнение X вместо параметра Op2. Однако, как правило, это не проявляется на электромагнитных или других излучениях, генерируемых при исполнении операций ADD и SUB, так как меняется только используемый адрес (при этом адрес X не является адресом Op2). При этом считывание данной по первому адресу или по другому адресу одного и того же компонента памяти в принципе оставляет одинаковые следы. Получают операцию ADD, которая может быть немного более медленной, чем обычная операция ADD, так как она вычисляет явно бесполезное дополнение X (которое в дальнейшем не используют), но зато сам факт вычисления этого дополнения позволяет получить такую же сигнатуру, что и для операции SUB. Согласно варианту выполнения, дополнение представляет собой этап, осуществляемый аппаратным способом параллельно с другими этапами, и не замедляет операцию ADD.

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

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

Согласно варианту выполнения, некоторые модели применяют только для апплетов, записанных в памяти определенного типа (например, в постоянной памяти ROM). Обычно память ROM содержит строго контролируемые апплеты, так как они были в обязательном порядке «загружены» на этапе маскирования компонента ROM, что предполагает знание апплета изготовителями этого компонента ROM, которые, следовательно, могут проверить его содержимое. Для многих типов апплетов (и, в частности, для апплетов Java) легко (что известно из предшествующего уровня техники) получить исходный код апплета, даже если располагают только его бинарным кодом (что может быть случаем вышеуказанных изготовителей).

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

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

- первую зону, доступную для третьих лиц, для контролируемой загрузки апплетов согласно первому уровню защиты, и

- вторую зону, доступную для изготовителя устройства, для загрузки корректоров ("patchs", "softmasks" и т.д.) или апплетов (в случае необходимости, обновлений апплетов), при этом, как правило, вторую зону контролируют согласно второму уровню защиты (часто более высокому, чем первый уровень защиты).

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

Таким образом, адаптируя используемые модели в зависимости от типов и/или зон памяти, создают еще большие трудности хакеру в характеризации команд, так как апплеты характеризации, которые могут быть загружены хакером, не подходят для всех апплетов и, в частности, для апплетов, записанных в запоминающих устройствах определенного типа или в определенных зонах памяти, считающихся более чувствительными и не доступными для хакера. Это может, в частности, относиться к системным апплетам, таким как апплеты, обеспечивающие функции аутентификации или функции совместного пользования элементов удостоверения личности ("credentials" на английском языке). Функции аутентификации могут, в частности, включать в себя биометрическую аутентификацию (проверка отпечатков пальцев при помощи технологии "match-on-card", проверка радужной оболочки и т.д.), проверку паролей, PIN-кодов и т.д. Функции совместного пользования элементов удостоверения личности могут включать в себя, например, функции совместного пользования PIN-кодом при помощи системного апплета, позволяющего избежать запроса одного и того же PIN-кода со стороны апплетов пользователя, что сказалось бы на доступности использования электронного устройства (обычно у пользователей вызывает раздражение необходимость вводить несколько раз один и тот же секретный код) и даже на безопасности. Действительно, каждое новое введение PIN-кода может стать объектом атаки (социальная инженерия, например, когда кто-либо может подсмотреть вводимый PIN-код и его запомнить, или система шпионажа "key logger", то есть распознавание нажатия кнопок). Кроме того, каждая новая передача PIN-кода в электронное устройство потенциально может стать объектом атаки.

Активация моделей одной команды происходит альтернативно в соответствии с некоторыми правилами, определяемыми целью приложения. Например, все модели можно активировать произвольно, при этом правило для апплета можно определить в соответствии с механизмом, описанным в патентной заявке FR 2903508 B1 («Защита программы, интерпретируемой виртуальной машиной», дата подачи 10 июля 2006 года), то есть можно учитывать уплотненный апплет (например, результат функции SHA-1, примененной к бинарному коду апплета), чтобы менять модели по-разному для одной и той же команды в зависимости от того, принадлежит она к одному апплету или к другому.

Альтернативные модели можно применять ко всем командам или к совокупности наиболее критичных и/или наиболее часто вызываемых команд. В частности, можно иметь в виду команды, обеспечивающие доступ к запоминающим устройствам типа NVRAM или EEPROM, которые можно наиболее легко детектировать посредством анализа потребления, так как они являются наиболее энергоемкими.

Согласно варианту выполнения, эта защитная мера имеет следующие последствия.

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

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

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

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

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

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

Согласно варианту выполнения, наиболее частыми командами являются: sload, sconst_0, baload, getfield_a_this, sstore, и защищают именно подгруппу из этих команд (и даже все эти команды).

Интерпретаторы (например, типа JVCM от JavaCard Virtual Machine) часто являются программами, разработанными на языке Си. Поэтому можно изменить интерпретатор в рамках этого языка, что обеспечивает высокую оперативность (его можно легко адаптировать от одного устройства к другому, которые могут, например, иметь процессор разного типа).

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

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

Фиг.2 иллюстрирует защиту апплета согласно варианту выполнения. На фиг.2 OPi обозначает команду номер i (опкодом которой является OPi). Ri обозначает правило этого апплета, соответствующее команде OPi. Правило Ri может, например, определять алгоритм селекции исполняемого кода для команды OPi. Речь может идти об обычном произвольном псевдоалгоритме, но в то же время речь может идти также об алгоритме, который хотя и является произвольным в том смысле, что его нелегко предвидеть, но выбирает разные коды с неодинаковой степенью вероятности. OP.SEQi обозначает этап исполнения команды OPi в последовательности команд, образующей апплет. Код, исполняемый на этапе OP.SEQi, не всегда является одним и тем же и зависит, с одной стороны, от команды OPi, определяющей функцию, которую должен реализовать код, и от правила Ri, определяющего, какой код (из всех кодов, реализующих эту функцию) должен быть исполнен.

Таким образом, виртуальная машина согласно варианту выполнения, представленному на фиг.2, генерирует, - на основании апплета, представленного рядом команд (OP1, OP2, ОР3, …), на основании ряда правил (R1, R2, R3, …) и на основании ряда групп кодов (Коды OP1, Коды OP2, Коды OP3, …), причем каждая группа кодов связана с одной командой, - последовательность исполнения (OP.SEQ1, OP.SEQ2, OP.SEQ3, …), реализующую задачи, предусмотренные в апплете, но применяющую произвольно выбранные коды.

Разумеется, настоящее изобретение не ограничивается вариантом выполнения, описанным выше в качестве примера; оно охватывает и другие варианты.

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

Защищаемые апплеты не ограничиваются апплетами JavaCard и могут быть, например, апплетами .NET или апплетами Multos.