СПОСОБ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ ИГРОВЫХ УСТРОЙСТВ И ИГРОВОЕ УСТРОЙСТВО ДЛЯ ЕГО ОСУЩЕСТВЛЕНИЯ Российский патент 2007 года по МПК G06F21/00 

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

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

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

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

В одной из реализаций изобретения к порту внутреннего игрового контроллера игровой машины (или иным образом) подключается безопасная смарт-карта или другое модульное устройство памяти. Плата игрового контроллера содержит центральный процессор (CPU), память и другие элементы управления игровой машиной. Игровая программа может храниться на запоминающем устройстве большой емкости, например на считываемом CD-ROM, жестком диске или флэш-устройстве, и соединяться с игровым контроллером через порт ввода-вывода. В настоящем документе подключаемый модуль обозначается словом донгл (защитное устройство). Донгл программируется так, чтобы принимать зашифрованный "запрос" CPU и давать на него зашифрованный "ответ". Если CPU определяет, что ответ правильный, то CPU убеждается в том, что программа истинна (т.е., что игровая программа правильна и разрешена к использованию на данной конкретной игровой машине и у данного покупателя) и игра может начаться. Обмен запрос-ответ может совершаться перед началом каждой игры на машине или в любое другое время.

Если ответ донгла неправилен, то CPU выдает команду на остановку игры.

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

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

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

Фиг.1 - Перспективный вид игровой машины, в которой имеется игровой контроллер и защитное устройство (донгл) в соответствии с одной из реализаций изобретения.

Фиг.2. Иллюстрирует основные функциональные блоки игровой машины, представленной на фиг.1.

Фиг.3. Вид спереди обычной смарт-карты, выполняющей операции шифрования-дешифрования и выдающей определенный ответ на запрос CPU.

Фиг. 4. Схема процесса проверки одной из реализаций игрового программного обеспечения.

Фиг. Другое представление процесса верификации игрового программного обеспечения.

Фиг.6. Иллюстрация взаимодействия с материнской микроконтроллерной платой (ММВ) смарт-карты и запоминающего устройства большой емкости.

Фиг.7. Иллюстрирует использование смарт-карты, подключенной к каждой плате игровой машины для обеспечения безопасной связи между платами.

Фиг.8. Иллюстрирует различные типы данных, хранимых на запоминающем устройстве большой емкости (например, CD или жесткий диск).

Фиг.9. Иллюстрирует протокол связи между платами.

Фиг.10. Иллюстрирует обмен ключами шифрования и дешифрования между смарт-картами и несколькими платами для обеспечения безопасной связи между платами.

Фиг.11. Иллюстрирует основные функциональные блоки безопасной микроконтроллерной платы игровой машины, предотвращающие копирование игрового программного обеспечения и предотвращающие внешнее считывание безопасных данных.

Фиг.12. Иллюстрирует пример металлической разводки, проходящей через безопасное покрытие, покрывающее зону безопасности контроллера, с помощью которой попытка доступа к зоне безопасности разрывает цепь и приводит к стиранию безопасной памяти.

Фиг.13. Вид сбоку контроллера, демонстрирующий безопасную зону, прикрытую безопасным колпаком.

Фиг.1. Представляет собой перспективный вид игровой машины 10, в которой использовано настоящее изобретение. Машина 10 состоит из дисплея 12, который может быть дисплеем на тонкопленочных транзисторах (TFT), жидкокристаллическим дисплеем (LCD), катодной электронно-лучевой трубкой (CRT) или иным видом дисплея. Второй дисплей 14 обеспечивает игровые данные или другую информацию дополнительно к дисплею 12.

Монетный механизм 22 принимает монеты или жетоны одного или нескольких достоинств для генерации кредита, чтобы играть в игры на машине 10. Щель 24 оптического считывающего устройства и принтера принимает билеты, считываемые машиной, и выдает распечатанные билеты для использования в безналичной игре. Приемник банкнот 26 принимает банкноты различного достоинства.

Монетный поднос 32 принимает монеты или жетоны из бункера во время выигрыша или обналичивания средств игроком.

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

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

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

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

Плата связи 42 состоит из обычных схем для соединения игровой машины 10 с локальной сетью (LAN) или сетью другого типа с использованием протокола Ethernet или другого протокола.

Игровой контроллер 44 содержит память и процессор для выполнения хранимых в памяти программ. Игровой контроллер 44 выполняет игровую программу.

Периферийные устройства/платы подключаются к игровому контроллеру 44 через шину. Периферия может состоять из устройства проверки подлинности банкнот 45, детектора монет 46, устройства считывания смарт-карты или другого типа кредитной карты 47, устройства ввода информации пользователем 48 (например, кнопки или сенсорный экран). Аудиоплата 49 преобразует закодированные сигналы в цифровые сигналы для громкоговорителей. Контроллер дисплея 50 преобразует закодированные сигналы в пиксельные сигналы для их отображения на дисплее 51.

Игровой контроллер состоит из CPU, программной оперативной памяти RAM, а также других схем управления и эксплуатации игровой машины. Одна разновидность контроллера подробно описана ниже на фиг.11.

Контроллер 44 оборудован портом ввода-вывода смарт-карт для электрического подключения контактных площадок питания, часов и серийного порта ввода-вывода стандартной безопасной смарт-карты 54 (также называемой в настоящем документе донгл 54), подобных тем, которые широко используются банками. Такие смарт-карты являются чрезвычайно безопасными, а их физическая конструкция и работа соответствуют хорошо известным стандартам ISO, включенным в настоящий документ посредством ссылки на них. Обзор смарт-карт и их функций безопасности приведен в статьях "Обзор смарт-карт безопасности", Сиу-чэнь Чан, 1997, которая находится в Интернет по адресу: http://home.hkstar.com/`alanchan/papers/smartCatdSecurity/ и "Технология и безопасность смарт-карт", которая находится в Интернет по адресу http^/people/cs.uchicago.edu/`dinoj/smartcard/secunty.html. Обе статьи включены в настоящий документ посредством ссылки на них для демонстрации глубокого знания безопасности смарт-карт.

Фиг.3. Упрощенный вид спереди стандартной смарт-карты (донгл 54). Карточка сделана из пластика. В нее встроен кремниевый чип 58 (показанный пунктирным контуром), содержащий микропроцессор (например, 8-битовый) и память. Печатная схема 60 обеспечивает металлические контактные площадки для питающего напряжения, заземления, часов и серийного ввода-ввывода. Смарт-карта спроектирована по стандартам ISO и защищена от перехвата содержащейся в ней информации, поэтому хранимое на ней программное обеспечение не может быть считано или скопировано с использованием практических методов.

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

1. Донгл должен иметь возможность хранить данные, которые являются нечитаемыми и некопируемыми через доступ к его контактным площадкам ввода-вывода.

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

3. Донгл должен выполнять функции шифрования и дешифрования.

4. Донгл должен обеспечивать безопасную хэш-функцию.

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

В одной из реализации донгл получает данные запроса от CPU и выполняет обработку запроса. Обработанные данные безопасно хранятся в донгле. Функцией такой обработки может быть любая функция. Функция может быть частным или стандартным алгоритмом шифрования, в котором для создания расшифрованного варианта запроса используются секретные ключи, например RSA, AES, 3DES или Эллиптические кривые. Ключи шифрования для данной функции хранятся в донгле. CPU расшифровывает ответ донгла с использованием своего секретного ключа (ключей), которые являются двойниками секретных ключей донгла, и сравнивает ответ с ожидаемым ответом. Если ответы совпадают, то CPU знает, что смарт-карта верна. Игровая программа продолжается обычным образом.

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

На шаге 63 производитель игровой машины или уполномоченный покупатель вставляет донгл безопасности в порт ввода-вывода игрового контроллера для установления связи с CPU (или подключает его другим образом). Обычно производитель вставляет донгл до поставки машины покупателю. Донгл может также распространяться вместе с игровой программой. Донгл программируется так, чтобы обрабатывать запрос от CPU и давать ответ. Только определенный ответ позволяет продолжить выполнение игровой программы. Донгл обычно остается в игровой машине.

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

На шаге 65, до начала игры на игровой машине, CPU выдает запрос на получение ответа от донгла.

На шаге 67 донгл отвечает, a CPU определяет правильность ответа. Ответ может представлять собой зашифрованную версию запроса, использующего один или несколько шифровальных ключей программирования. CPU расшифровывает ответ и сравнивает его с ожидаемым ответом. Ожидаемый ответ может генерироваться CPU с использованием тех же функций, которые используются донглом. Из методов шифрования-дешифрования используются методы RSA, AES и 3DES. В данный документ включены опубликованные стандарты на эти методы путем ссылки на них. Шифрование-дешифрование может использовать один и тот же секретный ключ (симметричный алгоритм) или разные ключи шифрования-дешифрования (ассиметричный алгоритм). По методу RSA отправитель шифрует сообщение с использованием открытого ключа получателя, а получатель расшифровывает сообщение, используя закрытый ключ отправителя. Открытый и закрытый ключи математически связаны.

На шаге 69, если CPU определяет, что ответ донгла является ожидаемым ответом, то CPU продолжает нормальную игровую программу (шаг 71) и может выдать сигнал тревоги или другое указание на то, что донгл не является сертифицированным. Это говорит о том, что программное обеспечение игровой машины является незаконным или что запустить программное обеспечение пытается несанкционированный пользователь.

Фиг.5. другим образом представляет процесс, показанный на фиг. 4. На фиг.5 игровой контроллер 44 (хост) выполняет нормальный программный поток до тех пор, пока не получает инструкцию выдать запрос (шаг 74) донглу 54. Донгл 54 отвечает (шаг 76) на запрос сообщением, уникальным образом определенным секретной программой/данными, находящимися в чипе памяти донгла. На шаге 78 хост проверяет ответ. Если ответ неправилен, то хост определяет сбой запроса донгла (шаг 80) и может, например, остановить нормальный программный поток. Если ответ правилен, то хост продолжает нормальный программный поток. С помощью этого метода обеспечивается весьма малая задержка в нормальном потоке программы, так что процесс проверки может использоваться до начала каждой игры.

Процедура запроса-ответа донгла может проводиться на любом этапе нормального потока программы.

Ниже представлены определенные приоритетные подробные спецификации одного из типов донгла. Предпочтительные спецификации для изобретения не нужны.

Подробные спецификации запроса донгла

СР Защита от копирования

CRP Протокол запроса-ответа

DR Запрос донгла

GAL Групповая/вентильная матричная логика

RNG Генератор случайных чисел

DRMF Сбой запроса донгла

MAC Код подлинности сообщения

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

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

1.1. Донгл

Основные требования к донглу состоят в следующем: 1). Это отдельное устройство, которое может связываться с игровым контроллером; 2). Это устройство может хранить данные, которые не могут читаться и копироваться с использованием практических методов. В настоящем изобретении донглы используются для создания протоколов зароса-ответа.

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

1.1.1. Типы донглов

- Смарт-карты и управляющие чипы смарт-карты.

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

- Микроконтроллеры общего назначения

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

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

- Групповая/вентильная матричная логика (GAL) или устройства с программируемой логикой (PLD).

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

- Стандартные решения, предоставляемые такими компаниями, как, например, "Алладин".

1.2. Предпочтительные требования к донглам

R1 Донгл должен хранить данные, которые нельзя прочесть или скопировать извне.

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

R3 Донгл должен выполнять, как минимум, одну стойкую несимметричную функцию шифрования для шифрования и цифровой подписи, например RSA или Эллиптические кривые.

R4 Донгл должен выполнять, как минимум, одну стойкую симметричную функцию, например AES или 3DES.

R5 Донгл должен выполнять, как минимум, одну безопасную хэш-функцию, например SHA-1 или SHA-256.

1.3. Предпочтительные требования к запросам донгла (DR)

В настоящем разделе приведен перечень общих требований, которым должны отвечать DR.

R1 DR не должен выполнять никаких "важных функций игрового устройства".

R2 DR должен выполнять сбой DR (например, УСЛОВИЕ ОСТАНОВКИ). УСЛОВИЕ ОСТАНОВКИ заставляет DR выполнять ОСТАНОВКУ игровой машины.

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

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

R5 Следует реализовывать разные типы DR.

R6 Каждый комплект DR должен использовать собственные алгоритмы.

1.4. Статические запросы донгла

Существуют два главных вида запросов донгла: статические DR и динамические DR.

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

Процедура запроса для статического DR работает следующим образом:

х=CONST_CHALLENGE

у=CONST_RESPONSE

у′=DR(x)

if(!verify(y,y′))

Malfunction ()

else

продолжить нормальное исполнение программы.

Значения х и у хранятся в приложении хоста, у‘ является результатом DR. Значения CONST_CHALLENGE и CONSTJRESPONSE являются только символами-наполнителями для различных пар запрос-ответ.

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

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

Функция проверки проверяет соответствие у′ ожидаемому значению. Самой простой функцией проверки будет, например, взаимно однозначное сравнение.

1.5. Динамические запросы донгла

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

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

Алгоритмами симметричного шифрования могут служить AES, TripleDES или TEA с ключами различной длины.

1.5.1. Запросы донгла, использующие симметричное шифрование

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

х=getRand ()ЗапросУ=f_kpub, (x) y′=DR (x)Ответif(!verify (y,y′))ПроверкаMalfunction () else 

продолжить нормальное исполнение программы.

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

Для симметричного шифрования может использоваться блочный шифр или поточный шифр.

1.5.2. Запрос донгла с использованием односторонних функций по ключу

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

Существует всего четыре типа функции MAC:

1). MAC на основе симметричных блочных шифров.

MAC на основе блочных шифров может использоваться для проверки содержания донглов. Подходящим типом является СВС-МАС на основе DES, 3DES или AES.

2). MAC на основе хэш-функций.

Это просто увязка ключа с вводимыми данными хэш-функции.

3). Заказные MAC.

Подходящими типами могут служить ММА или MD5-MAC.

4). MAC для поточных шифров.

Эти MAC предназначены для поточных шифров. Они могут реализовываться путем объединения выходной контрольной сумму CRC с ключом.

Для запроса донгла следует использовать метод 2 или 3.

1.5.3. Запрос донгла с использованием несимметричного шифрования

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

Несимметричный DR выглядит следующим образом:

х=getRand ()ЗапросУ=f_kpub, (x) x′=DR(y)Ответif(!verify(x,x′))ПроверкаMalfunction () else 

продолжить нормальное исполнение программы.

В данном случае х шифруется открытым ключом основным приложением и направляется донглу. Донгл расшифровывает открытый ключ и возвращает его.

Функция проверки обычно проверяет у′ на соответствие ожидаемому значению.

Для несимметричного шифрования может использоваться RSA.

1.6. Сбой запроса донгла (DRMF)

Сбой запроса донгла (DRMF) представляет собой функцию, которая реализуется, когда ответ донгла не соответствует ожидаемому.

DRMF не должен влиять на игровое поведение, за исключением только вызова условия ОСТАНОВИТЬ. Существуют несколько типов условий ОСТАНОВИТЬ, а также разные методы их вызова. Например, условие ОСТАНОВИТЬ может сообщаться или не сообщаться пользователю. Должны быть DRMF с различным поведением в системе в одно и то же время. Ниже представлены подходящие DRMF. Выбор делается, исходя из обоснованных ограничений.

Следующие DRMF используют нормальное исключение или процедуры операций:

DRMF1 Блокирует машину. Никакие сообщения пользователю не передаются. Необходима повторная инициация машины.

DRMF2 То же, что и DRMF1, за исключением того, что пользователь получает информацию о том, что машина блокирована.

DRMF3 То же, что и DRMF1, за исключением того, что блокировка снимается путем перезагрузки.

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

DRMF5 Перезагрузка машины путем перезагрузки аппаратных средств

DRMF6 Запрет на пуск машины.

DRMF7 Блокируется ввод со стороны пользователя.

DRMF8 Блокируется ввод со стороны пользователя, за исключением "обналичивания".

Предпочтительные подробные спецификации на донгл на смарт-карте

1.7. Электронная игровая машина

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

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

1.7.1. Смарт-карта

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

Для формирования отношений доверия между изготовителем и предприятием смарт-карта и вся информация на ней должна оставаться собственностью изготовителя.

1.7.2. Предприятие

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

Контроль предприятий есть метод, посредством которого изготовитель EGM осуществляет региональный контроль за распространением программного обеспечения.

1.7.3. Данные приложения

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

Для EGM, работающих, в целях исполнения игр, от удаленного сервера приложений, часть данных приложения находится на MSD удаленного сервера.

1.7.4. Устройство хранения большой емкости

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

1.8. Определение ключей

В настоящем разделе описываются все ключи, которые будут использоваться в концепции безопасности.

1.8.1. Ключ доступа смарт-карты

Каждая EGM имеет, как минимум, один ключ доступа смарт-карты (SCAK). Используя этот SCAK, EGM может проверяться SC и создавать проверенное и зашифрованное соединение между собой и SC. Если SCAK отсутствует или неправилен, то смарт-карта отказывает в доступе и EGM не выполняет игру.

SCAK хранится в надежном устройстве-хранилище EGM. Это значит, что к нему не должно быть доступа и что SCAK не может быть никаким образом скопирован с EGM.

1.8.2. Игровой ключ

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

Игровой ключ хранится на SC, соединенном с Материнской микроконтроллерной платой (ММВ), и используется для расшифровки.

1.8.3. Пара открытый-закрытый ключ изготовителя

Конкретная пара открытого-закрытого ключа изготовителя используется для идентификации смарт-карт как смарт-карт данного изготовителя. Открытый ключ хранится на каждой SC. Закрытый ключ используется для подписи открытого ключа SC (уникального для каждой SC). Данная подпись используется для идентификации конкретного изготовителя SC.

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

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

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

Пара открытый-закрытый ключ предприятия

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

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

1.8.4. Ключ проверки операционной системы

Ключ проверки операционной системы (OSVK) подобен ключу изготовителя и представляет собой пару открытого-закрытого ключей RSA. Он используется для проверки подлинности загрузчика операционной системы (OS) и образа OS на устройстве с большой емкостью хранения информации при запуске EGM.

Поэтому эти два модуля подписаны закрытым ключом OSVK. При запуске EGM с использованием открытого OSVK проверяются подписи загрузчика и образа. Открытый ключ OSVK хранится в каждой EGM изготовителя. Если подпись верна, то это гарантирует, что OS не была изменена и ей можно доверять.

Открытый OSVK хранится на каждой EGM. Поскольку он используется для проверки подписей, то ему самому нужно доверять, поэтому он должен храниться в защищенной от записи зоне памяти системы (предпочтительно в BIOS). Поскольку с помощью OSVK подписи создаваться не могут, то нет нужды защищать его от чтения.

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

1.9. Предпочтительное детальное описание архитектуры платы материнской микроконтроллерной платы (ММВ)

У описанных в настоящем документе концепциях безопасности существуют две цели. Первая цель заключается в том, чтобы предотвратить со стороны кого-либо копирование 1:1 игровой программы и запуск ее на другой EGM. Вторая цель состоит в защите интеллектуальной собственности (IP), к которой относятся программное обеспечение и данные, от несанкционированного доступа, копирования и (или) модификации атакующим.

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

1.9.1. Электронная игровая машина (EGM) на одной плате

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

SC обладает криптографическими возможностями и возможностями PKI (инфраструктура открытого ключа), что позволяет производить шифрование и проверку подлинности. Если SC не подключена к ММВ, то EGM не запустит игру. В ней также хранятся секреты и другие данные, проверяемые в ходе выполнения игры. Это предотвращает запуск игры без SC и от копирование игры 1:1 и запуска ее на другой EGM.

Защита IP обеспечивается путем хранения данных приложения для EGM в зашифрованном виде на Устройстве с большой емкостью хранения информации (MSD). Ключ для их расшифровки при запуске, так называемый игровой ключ (GK), хранится на SC, подключенной к ММВ.

Фиг.6 показывает архитектуру EGM с одной платой. ММВ 84 имеет зону безопасности (SA) для хранения SCAK в защищенной среде и для выявления возможных изменений в BIOS. SC_MMB 86 подключается к устройству считывания смарт-карты, соединенному или находящемуся на ММВ 84. MSD 88 может быть подключенным к ММВ периферийным устройством или устройством, встроенным в ММВ. Поскольку данные приложения на MSD находятся в зашифрованном виде, нет особой необходимости в безопасности самого MSD.

1.9.2. Электронная игровая машина (EGM) на нескольких платах

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

Фиг.7 показывает архитектуру безопасности EGM, если SC имеются на обеих платах.

Для простоты, в настоящем документе показывается только процесс для EGM на двух платах. Хотя концепция может быть пояснена более чем на двух платах. Поэтому дополнительная плата называется "Второй платой" 90, а не обязательная SC 92, подключенная к этой плате, называется SC_SB.

Обзор системы защиты безопасности и последовательности пуска

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

1.10. Пуск EGM

Процесс загрузки EGM может быть разделен на две разные задачи, которые более подробно описаны в последующих разделах.

- Последовательность загрузки операционной системы (OS).

- Последовательность пуска приложений.

Последовательность загрузки OS касается пуски OS, тогда как последовательность пуска приложений используется для расшифровки программных данных приложения и запуска игры.

Для запуска системы ММВ должна содержать два разных ключа:

Открытый OSVK: для проверки загрузчика OS и образа OS, хранимого на MSD.

SCAK: для доступа к SC и чтения из нее GK.

Открытый ключ OSVK хранится на каждой EGM. Поскольку он используется для проверки подписей, он должен заслуживать доверия, поэтому он хранится в зоне памяти системы, защищенной от записи (например, в BIOS).

Поскольку подписи с помощью открытого OSVK не создаются, нет необходимости защищать его от чтения.

1.10.1. Безопасная последовательность загрузки операционной системы

Основная работа последовательности загрузки OS заключается в том, чтобы гарантировать, что загрузчик OS и образ OS на MSD не изменены. Для этой проверки эти два программных модуля подписываются закрытым OSVK. До их исполнения подпись каждого модуля проверяется с помощью открытого OSVK. Первые два шага выполняются BIOS, а другие два шага выполняются загрузчиком OS:

1. BIOS - загрузка загрузчика OS из MSD.

2. BIOS - проверка подписи загрузчика OS открытым ключом OSVK и пуск загрузчика.

3. Загрузчик OS - загрузка образа OS из MSD.

4. Загрузчик OS - проверка подписи образа OS и инициирующих приложений с помощью открытого OSVK, запуск образа OS и инициирующих приложений.

1.10.2. Последовательность пуска приложений

После запуска OS контроль над системой получает инициирующее приложение. Теперь для доступа к SC, чтения GK и дешифрования приложений используется SCAK. Затем приложения проверяются на подлинность, и если проверка прошла, то запускается игра.

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

1. Установить проверенное и безопасное соединение в SC, используя SCAK.

2. Получить GK в SC.

3. Загрузить и расшифровать данные приложения.

4. Запустить приложение.

5. Приступить к выполнению игры.

1.10.3. Логические диски устройства с большой емкостью хранения информации

Как показано на фиг.8, MSD может быть разделено на 3 секции:

- Загрузчик OS 94. Это загрузчик OS для ММВ, подписанный закрытым ключом OSVK.

- Образ OS и инициирующие приложения 96: Это образ OS и инициирующие приложения для ММВ, подписанные закрытым ключом OSVK. Они обеспечивают доступ к SC_MMB.

- Зашифрованные приложения 98: Это зашифрованные приложения для ММВ и возможных дополнительных плат. Они расшифровываются во время пуска с помощью GK, который хранится в SC_MMB.

11.1. Запросы к донглу

Во время выполнения игры ММВ нуждается в проверке текущего подсоединения SC_MMB. Это может быть выполнено разными способами, например:

- Прямые команды: EGM направляет прямые команды SC для того, чтобы убедиться, что карта на месте.

- Общие запросы к донглу: Запросы к донглу уже описаны выше.

11.2. EGM с несколькими платами

Если EGM имеет несколько плат, то шифруются также коммуникации между ММВ и дополнительными платами. Для простоты в настоящем документе показан только процесс для EGM с двумя платами, хотя концепция может быть распространена на более чем две платы.

Для данного случая на этапе пуска EGM устанавливается шифрованное и проверенное соединение между ММВ и дополнительными платами. Как показано на фиг.7, соединение состоит из двух отдельных соединений: одно от ММВ к второй плате, называемое "нисходящая линия связи", а другое от второй плате к ММВ, называемое "восходящая линия связи". Каждое из этих соединений шифруется разными ключами сессии. Но может использоваться один и тот же ключ. Ключи генерируются случайным образом и независимо на платах с помощью SC и могут изменяться в ходе выполнения приложения. Если на второй плате SC не имеется, то ключ "восходящей линии связи" генерируется самой платой. Шифрование-дешифрование данных, направляемых по этой линии связи, может производиться в программе или донгле, но не в SC.

Рекомендуется использовать для данного симметричного шифрования Улучшенный стандарт шифрования (AES), а именно алгоритм Rijndael.

11.2.1. Протокол безопасности

Для осуществления данного шифрования и проверки подлинности меры безопасности реализуются либо внутри, либо над сетевым слоем или над транспортным слоем, если говорить о стандартной модели сетевого протокола ISO/OSI. Это значит, что система работает с протоколами, ориентированными и не ориентированными на соединение.

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

Пример реализации заказного протокола безопасности показан на фиг.9, который говорит сам за себя. Однако также легко могут использоваться такие протоколы, как SSL/TLS или IPSec.

Физическая связь между ММВ и второй платой особой роли не играет. В этом примере используется протокол, ориентированный на соединение (например, TCP/IP) в Транспортном слое, поверх которого устанавливается Протокол безопасности. Он называется Безопасной линией связи между платами (SIBC). SIBC обладает всеми функциями по установке безопасного соединения для выполнения шифрования линии связи и для доступа к криптографическим функциям смарт-карты. Стек протокола равен на ММВ и на второй плате.

1.12.1.1. Пример протокола установления соединения и обмена ключами

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

Фиг.10 подразумевает, что на второй плате имеется смарт-карта. Если ее не имеется, то функции шифрования на второй плате выполняются в программе.

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

Протокол обмена ключами может повторяться во время выполнения основного приложения EGM. Рекомендуется обновлять ключи сессии (и обмениваться ими снова по описанному Протоколу обмена ключами) несколько раз в течение времени выполнения основной программы для снижения вероятности прослушивания кем-либо потока данных.

1.12.1.2. Пример генерирования ключа сессии

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

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

SC представляет собой в системе безопасное устройство. Она должна обеспечивать функциональность PKI, а также симметричное шифрование и безопасный хэш-алгоритм. Кроме того, она также должна обеспечить безопасное хранение данных. Доступ к криптографическим функциям и безопасным данным должен гарантироваться, только если приложение на ММВ было проверено на подлинность SC путем использования SCAK.

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

Во время выполнения основного приложения, если к EGM подключена SC_MMB, выполняются непрерывные проверки. Если отсутствует SC_MMB, EGM не может работать, поскольку не может дешифровать данные приложения. В EGM с несколькими платами зашифрованная связь между ММВ и второй платой без SC не может быть установлена.

11.3. Смарт-карта (SC) на ММВ

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

11.3.1. Содержание SC_MMB

SC_MMB содержит:

- Идентификационные номера (ID) предприятия (казино, группа казино и т.д.), идентификационные номера страны.

- Открытые-закрытые пары ключей.

- Подписи для открытого ключа. Эти подписи создаются с помощью закрытых ключей изготовителя.

- Открытые ключи изготовителя.

- Уникальный открытый ключ предприятия для проверки подлинности данных, которые будут храниться на EGM (например, GK, лицензия и т.д.) - не обязательно.

- Ключи игры для игры.

- Секреты запроса к донглу.

ID предприятия и ID страны показывают, какому предприятию и в какой стране разрешено использовать SC.

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

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

Открытый ключ изготовителя используется для проверки изготовителем подлинности другого устройства. Как было сказано выше (об установлении безопасного соединения между ММВ и второй платой), SC "А" посылает подписанный открытый ключ SC "В". SC "В" проверяет эту подпись с помощью открытого ключа. Если подпись действительна, то SC "А" знает, что SC "В" является устройством изготовителя.

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

GK используется для дешифрования приложений и запуска игры.

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

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

11.3.2. Требования к SC_MMB

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

Хранение данных

SC должна обеспечивать:

- Долговременную память для ID предприятия и ID страны.

- Безопасное хранение несимметричных ключей, например RSA.

- Безопасное хранение GK (а также данных лицензии).

- Безопасное хранение SCAK.

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

Криптография

SC должна позволять:

- Создавать пару открытых-закрытых ключей. Закрытый ключ ни при каких обстоятельствах не должен покидать SC.

- Дешифровать данные с помощью закрытого ключа.

- Шифровать данные открытым ключом.

- Хранить внешние открытые ключи и использовать их для шифрования данных и проверки подписи.

- Создавать цифровые подписи.

- Создавать симметричные ключи сессии (например, AES, 3DES) и возвращать их основному приложению.

- Генерировать случайные числа (для создания ключей).

- Обеспечивать симметричные алгоритмы для шифрования-дешифрования внешних данных.

Функциональные требования

SC должна:

- Создавать проверенный и безопасный канал связи с ММВ.

1.14. Смарт-карта на второй плате

Если ко второй плате смарт-карта не подсоединена, то все алгоритмы и основные механизмы хранения должны быть реализованы в программе. Это значит, что вторая плата всегда ведет себя так, как если бы к ней была подключена SC.

Ниже SC на второй плате называется SC_SB.

1.14.1. Содержание SC_SB

SC_SB содержит:

- Пары открытых-закрытых ключей для проверки подлинности между платами.

- Подписи для открытых ключей. Такие подписи создаются с помощью закрытых ключе изготовителя.

- Открытые ключи изготовителя.

Если SC_SB не является частью EGM, то пара открытого-закрытого ключа для проверки подлинности между платами, а также открытый ключ должны интегрироваться в программу второй платы. Это обеспечивает работу ММВ одинаковым образом, не зависимо от присутствия SC_SB.

Термины закрытый-открытый ключ, подписи для открытого ключа и открытый ключ имеют то же значение, что и для SC_MMB.

SC_SB является сменным устройством.

1.14.2. Требования к SC_SB

Требования к SC_SB похожи на требования к SC_MMB. Однако для SC_SB не требуется хранить GK или данные лицензии.

Хранение данных

SC должна обеспечивать:

- Безопасное хранение несимметричных ключей, например RSA.

- Безопасное хранение сетевого сертификата.

Криптография

SC должна позволять:

- Создавать пару открытых-закрытых ключей. Закрытый ключ ни при каких обстоятельствах не должен покидать SC.

- Дешифровать данные с помощью закрытого ключа.

- Шифровать данные открытым ключом.

- Хранить внешние открытые ключи и использовать их для шифрования данных и проверки подписи.

- Создавать симметричные сессионные ключи (например, AES, 3DES...) и возвращать их основному приложению

- Генерировать случайные числа (для создания ключей).

Предпочтительное подробное описание процедуры генерации смарт-карты

1.15. Генерация смарт-карты

Процесс создания SC может быть разделен на три различные фазы:

Физическая генерация карты.

Загрузка программного обеспечения.

Персонализация.

Физическая генерация карты производится изготовителем карты.

На карту загружаются операционная система и программное обеспечение приложения. В зависимости от типа карты эта загрузка выполняется изготовителем SC или изготовителем игровой машины (EGM).

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

1.16. Базы данных изготовителя

Для отслеживания ключей, которые будут использоваться в системе безопасности, а также для автоматизации выпуска SC нужно создавать базы данных. Эти базы данных содержат только открытые ключи (открытые ключи смарт-карт), симметричные GK и серийный номер или ID смарт-карты (SC).

1.16.1. Открытые ключи смарт-карт ММВ

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

Генерация и регистрация этих пар открытых-закрытых ключей называется "персонализацией". Процесс персонализации производится после изготовления SC, но до того, как устройство отправляется покупателю.

1.16.2. Игровые ключи (GK)

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

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

1.16.3. Игровая база данных

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

1.17. Распространение игр

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

1.18. Термины

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

ПодписьХэш-значение, зашифрованное закрытым несимметричным ключом.Проверка подписиЗашифрованное хэш-значение расшифровывается открытым ассиметричным ключом, результат сравнивается с новым вычисленным хэш-значением подписанных данных. Если хэш-значения равны, то подпись верна.Ключ доступа к смарт-картеКлюч для доступа к конфиденциальным данным или функциям смарт-карты.

1.19. Сокращения

AES Улучшенный стандарт шифрования

DES Стандарт шифрования данных

EGM Электронная игровая машина

GK Игровой код (код игры)

IP Интеллектуальная собственность

ММВ Материнская микроконтроллерная плата

MSD Устройство хранения большой емкости

OS Операционная система

OSVK Ключ проверки операционной системы

PKI Инфраструктура открытого ключа

ROM Постоянное запоминающее устройство

RSA Алгоритм открытого ключа Ривеста, Шамира, Алдемана

SC Смарт-карта

SCAK Ключ доступа к смарт-карте

SIBC Безопасная связь (безопасное соединение, коммуникация) между платами.

TCP Протокол контроля передачи

1.20. Предпочтительная подробная спецификация на безопасный модуль платы микроконтроллера

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

Цель концепции с точки зрения аппаратных средств заключается в защите тех элементов на плате, которые считаются уязвимыми с точки зрения безопасности. В настоящем Разделе полностью описываются элементы с высоким риском. Зона вокруг элементов безопасности называется Безопасной зоной. Безопасная зона должна быть полностью изолирована. К сему относится также ряд мер по выявлению и предупреждению доступа несанкционированного лица к зоне. Если засечен посторонний доступ, то вся информация на плате стирается.

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

Модуль безопасности особенно пригоден для защиты описанной выше системы программного обеспечения смарт-карты.

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

1.21. Общие определения

В настоящем разделе описаны общие определения, касающиеся концепции безопасности.

1.21.1. Плата микроконтроллера

Как показано на фиг.11, Плата микроконтроллера 84 имеет Зону безопасности (SA) 107, в которой находится, как минимум, центральный процессор (CPU) 106 и набор микросхем 108, главная память (RAM) 110, процессор безопасности (SP) 112 и BIOS EPROM 113. Эти компоненты связаны через систему ШИНЫ 114. Устройство считывания смарт-карты 116 подключено к плате и находится в собственной зоне безопасности для предотвращения несанкционированного доступа к смарт-карте и линиями передачи данных. За пределами зоны безопасности могут находиться нечувствительные компоненты, показанные как блок 117, и батарейка 118.

1.21.2. Зона безопасности

Зона безопасности (SA) 107 защищает все чувствительные компоненты и линии передачи данных на плате. Она имеет серию датчиков, засекающих любую попытку проникновения. Если такая попытка обнаружена, то SP сбрасывает CPU, стирает чувствительные данные в зоне безопасности.

1.21.3. Процессор безопасности

Процессор безопасности (SP) 112 получает данные от всех датчиков зоны безопасности. К датчикам относятся система меандра, световые датчики и температурные датчики. При обнаружении проникновения центральный процессор удаляет все чувствительные данные на плате.

1.21.4. Чувствительные данные

Чувствительные данные защищены от изменения или чтения извне. К ним относятся расшифрованные данные приложения и секретные ключи. Чувствительные данные хранятся в памяти внутри зоны безопасности.

В данном разделе приводится концептуальный обзор механизмов безопасности платы микроконтроллера 84.

Предполагается, что игровое приложение, которое будет исполняться на плате 84, хранится на внешнем устройстве (например, на CD-ROM и приводе, компактной флэш-памяти, сервере и т.д.) только в зашифрованной форме. Расшифрованное и исполняемое приложение может находиться только в зоне безопасности 107.

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

SA имеет внешнее подключение только через разъемы ввода-вывода (I/O) 119. Через разъемы I/O 119 к плате 84 подсоединяются устройство с большой емкостью хранения (Рис.7) и другие устройства (например, устройства ввода, дисплеи, сетевые соединения и т.д.). Устройство чтения смарт-карты 116, которое позволяет легко вставлять и вынимать смарт-карту, обеспечивает системе гибкость с точки зрения обращения с секретным ключом и обмены ключами. В других реализациях смарт-карта подключается к плате 84 по проводам.

Все критические компоненты, которые хранят или передают чувствительные данные, помещаются внутри SA 107. К таким устройствам относятся CPU 106, RAM 110, микросхемы CPU 108, SP 112 и BIOS EPROM 113. Внутри SA 107 находятся также все шины данных и адресов.

Внутри SA 107 находятся все световые и температурные датчики, поэтому они не могут быть модифицированы извне.

Задача SP 112 заключается в контроле датчиков 122 (например, световых, проводных и температурных). Если какой-либо датчик обнаруживает вторжение, то SP 112 удаляет чувствительные данные внутри зоны безопасности.

Внутри SA 112 находится также BIOS EPROM 113. Иначе атакующее лицо могло бы заменить BIOS на вредоносный и извлечь чувствительные данные (через разъемы I/O 119) или запустить на плате несанкционированное программное обеспечение.

1.22 Определение зоны безопасности

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

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

Если вторжение выявляется, то SP 112 сбрасывает CPU 106, стирает чувствительные данные в зоне безопасности. Таким образом, атакующий не получает доступа к чувствительным данным, хранимым на плате.

Для простоты здесь описана только одна зона безопасности, но на плате могут иметься несколько зон безопасности. Все соединения и линии данных между SA также должны быть защищены.

1.23. Схема выявления вторжения

Схема выявления вторжения 122 должна контролировать соединения и другие параметры системы безопасности для выявления попыток несанкционированного доступа в зону безопасности 107. Ядром данной схемы является Процессор безопасности (SP) 112.

SP 112 управляет схемой выявления вторжения 122 и контролирует все датчики зоны безопасности 107. Если какой-либо из датчиков обнаруживает вторжения, то SP 112 активирует фазу стирания SA 107 и таким образом удаляет все чувствительные данные, хранимые в зоне безопасности.

Когда EGM выключена, то питание SP 112 получает от батарейки 118. Батарейка может помещаться внутри и снаружи SA 107.

1.24. Датчики зоны безопасности

В зоне безопасности 107 находятся по крайней мере три разных вида датчиков выявления вторжения. Они действуют независимо друг от друга, но все находятся под контролем SP 112.

- Система меандра со всех сторон.

- Световые датчики.

- Температурный датчик.

1.24.1. Система меандра - колпак зоны безопасности

Зона безопасности 107 закрывается системой меандра. Колпак из меандра создает зону безопасности SA 107 вокруг всех защищаемых элементов. Меандр контролируется на неразрывность с помощью схемы выявления вторжения (фиг.11). Через колпак нельзя проникнуть, не нарушив меандр и не разорвав его цепь.

Несанкционированный доступ к защищаемым элементам зоны контролируется. SA 107 должна быть полностью прикрыта системой меандра. Это значит, что все стороны SA 107 должны быть покрыты меандром.

Меандр 126 показан на фиг.12. Он представляет собой проводящий канал минимальной ширины (например, шириной 0,2 мм максимально) и с минимальным шагом. Проводящий канал 126 заполняет защищаемую зону серпантином. Используемые печатные платы (РСВ) должны строиться так, чтобы минимизировать риск ложной тревоги от световых датчиков.

На фиг.13 показан общий подход к защите зоны (зон) безопасности. Этот рисунок следует считать примером. Блоки 128 представляют пакеты интегральных схем. Со схемой обнаружения вторжения 122 меандр соединяет электрический соединитель 129.

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

1. Использовать колпак из РСВ 130 со слоем меандра 132, в том числе с защитой боковых сторон.

2. Осуществить гибкий печатный монтаж внутри прикрытой зоны с выводами для BIOS и разъема (с защитой боковых сторон).

3. Использовать стандартный колпак, например колпак GORE.

1.24.1.1. Колпак безопасности

РАЗМЕР. Размер колпака безопасности определяется во время компоновки платы микроконтроллера. Следует стремиться к наименьшему возможному размеру.

МАТЕРИАЛ. Используемый материал должен предотвращать ложное срабатывание световых датчиков.

1.24.1.2. Монтаж колпака

Для механической сборки колпака и предотвращения ложного срабатывания световых датчиков нужны монтажные кронштейны. Колпак надевается после сборки платы микроконтроллера.

1.24.1.3. Программирование и запуск SP

Окончательное программирование SP 112 производится во время сборки. Это значит, что после изготовления SP не имеет никакой программы. До сборки колпака приложение загружается в SP через механизм программирования. После закрытия колпака через установленный промежуток времени (который находится в пределах от 10 до 20 секунд) SP начинает контролировать схему выявления вторжения 122. По истечении этого времени при открытии колпака все чувствительные данные стираются.

1.24.2. Световые датчики

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

1.24.3. Температурные датчики

Температура внутри зоны безопасности 107 не должна превышать установленную в системе безопасности температуру. Эти температурные пределы устанавливаются для определения правильной работы системы.

1.25. Защищаемые элементы

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

Защищаемыми элементами считаются следующие компоненты, которые должны быть полностью изолированы (со всех сторон):

- BIOS EPROM.

- Процессор безопасности.

- Все компоненты, точки испытаний и сигналы схемы выявления вторжения, за исключением батарейки.

- Микроэлементы CPU.

- RAM на плате.

- CPU.

- Микросхемы ввода-вывода (I/O).

Защищаемыми элементами считаются следующие критические сигналы, которые должны быть защищены.

- Сигналы CPU.

- Сигнал сброса.

- 100% всех сигналов данных к микроэлементам CPU.

- Не менее 10% остальных сигналов к микроэлементам CPU.

- Сигналы микроэлементов CPU.

- Коммуникационные сигналы к SP.

- Не менее 10% всех сигналов адреса RAM.

- 100% всех сигналов данных RAM.

- Сигналы RAM.

- Не менее 10% всех сигналов адреса RAM.

- 100% всех сигналов данных RAM.

- Все другие сигналы шины на плате микроконтроллера.

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

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

ПОДПИСИ К ФИГУРАМ

Подписи к фиг.2

10 - К сети.

42 - Коммуникационная плата.

54 - Безопасный донгл (например, смарт-карта).

44 - Плата игрового контроллера.

45 - Устройство проверки банкнот.

46 - Детектор монет.

47 - Устройство чтения карт.

48 - Устройство ввода со стороны пользователя.

49 - Аудиокарта.

50 - Контроллер дисплея.

51 - Дисплей.

Подписи к фиг.3

Смарт-карта

Подписи к фиг. 4

Процесс проверки игровой программы

61 - Обеспечивается игровая программа, выполняемая основным CPU, которая требует надлежащего ответа донгла на запрос от центрального процессора.

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

65 - До начала игры процессор запрашивает ответ донгла.

67 - Обработка ответа для определения его соответствия ожидаемым характеристикам.

69 - Проверена ли игровая программа?

71 - Разрешить выполнение игры.

73 - Остановить работу игровой машины.

Подписи к фиг.5

44 - Нормальный поток программы.

74 - Запрос донгла.

76 - Ответ донгла.

78 - Проверка ответа - неправильный.

80 - Сбой ответа донгла, правильный - нормальный поток программы.

А - Запрос.

В - Ответ.

54 - Донгл - безопасное хранение.

Подписи к фиг.6

1. Содержит: ID предприятия, пару закрытый-открытый ключ, подпись открытого ключа, открытый ключ изготовителя, уникальный открытый ключ предприятия, игровой ключ, секреты запроса донгла.

88 - Зашифрованное устройство с большой емкостью хранения (MSD).

2. Архитектура безопасности игровой машины (EGM) с одной платой.

Подписи к фиг.7

1. Содержит: ID предприятия, пару закрытый-открытый ключ, подпись открытого ключа, открытый ключ изготовителя, уникальный открытый ключ предприятия, игровой ключ, секреты запроса донгла.

88 - Зашифрованное устройство с большой емкостью хранения (MSD).

2. Зашифрованная линия, 3. Линия связи вниз, 4. Линия связи вверх.

99 - Вторая плата.

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

6. Безопасная архитектура игровой машины (EGM) с несколькими платами.

Подписи к фиг.8

94 - Загрузчик операционной системы - загрузчик операционной системы ММВ (подписанный закрытым OSVK).

96 - Образ операционной системы - операционная система + инициирующие приложения ММВ (подписанные закрытым OSVK).

98 - Данные приложения (зашифрованы) - зашифрованные данные приложения (зашифрованы Игровым ключом).

1. Различные логические диски устройства большой емкости хранения.

Подписи к фиг.9

1. Слой приложения. 2. Транспортный слой, ориентированный на связь. 3. Физический слой. 4. Протокол стека Протокола расширенного слоя.

Подписи к фиг.10

Протокол обмена ключами

А. Приложение ММВ +... Б. Приложение второй платы... В. Шифрованное соединение, Нешифрованное соединение.

1. SC_MMB запрашивает открытый ключ от SC_SB.

2. Вторая плата направляет свой подписанный открытый ключ SC_MMB.

3. SC_MMB проверяет подпись.

4. SC_MMB создает случайный ключ сессии для связи вверх и зашифровывает его открытым ключом Второй платы.

5. ММВ направляет зашифрованный ключ сессии Второй плате.

6. Вторая плата/ SC_SB дешифрует ключ сессии с помощью своего закрытого ключа и передает его алгоритму программы.

7. Вторая плата запрашивает открытый ключ у SC_MMB через зашифрованную линию связи вверх.

8. ММВ направляет свой подписанный открытый ключ второй плате.

9. Вторая плата/SC_SB проверяет подпись.

10. Вторая плата/SC_SB создает случайный ключ сессии для связи вниз и шифрует его открытым ключом SC_MMB.

11. Вторая плата направляет зашифрованный ключ сессии в ММВ через уже зашифрованную линию связи вверх.

12. SC_MMB дешифрует ключ сессии с помощью своего закрытого ключа и передает его алгоритму программы.

13. ММВ направляет второй плате сообщение "обмен ключами завершен" через зашифрованную линию связи вниз.

14. Вторая плата отвечает ММВ на сообщение "обмен ключами завершен" через зашифрованную линию связи вверх.

Подписи к фиг.11

84 - Плата микроконтроллера.

117 - Дополнительные компоненты платы.

118 - Батарейка.

112 - Процессор безопасности.

122 - Схема обнаружения вторжения.

108 - Периферийные микроэлементы CPU.

119 - Контакты ввода-вывода.

116 - Устройства чтения смарт-карты.

1 - ЗОНА БЕЗОПАСНОСТИ

Подписи к фиг.13

Зона безопасности платы вблизи

1. Закрытая зона на ВЕРХНЕЙ стороне. 2. Слой меандра. 3. Второй РСВ (1 слой РСВ). 4. ВЕРХ. 5. НИЗ.

107 - ЗОНА БЕЗОПАСНОСТИ.

129 - Контакт.

132 - Слой меандра.

84 - Плата.

Подписи к фиг.10

1. Смарт-карта Главной микроконтроллерной платы запрашивает открытый ключ от смарт-карты Второй платы.

2. Вторая плата направляет свой подписанный открытый ключ смарт-карте Главной микроконтроллерной платы.

3. Смарт-карта Главной микроконтроллерной платы проверяет подпись.

4. Смарт-карта Главной микроконтроллерной платы создает случайный ключ сессии для связи вверх и зашифровывает его открытым ключом Второй платы.

5. Главная микроконтроллерная плата направляет зашифрованный ключ сессии Второй плате.

6. Вторая плата/смарт-карта Второй платы дешифрует ключ сессии с помощью своего закрытого ключа и передает его алгоритму программы.

7. Вторая плата запрашивает открытый ключ у смарт-карты главной микроконтроллерной платы через зашифрованную линию связи вверх.

8. Главная микроконтроллерная плата направляет свой подписанный открытый ключ Второй плате.

9. Вторая плата/смарт-карта второй платы проверяет подпись.

10. Вторая плата/смарт-карта Второй платы создает случайный ключ сессии для связи вниз и шифрует его открытым ключом смарт-карты Главной микроконтроллерной платы.

11. Вторая плата направляет зашифрованный ключ сессии в Главную микроконтроллерную плату через уже зашифрованную линию связи вверх.

12. Смарт-карта Главной микроконтроллерной платы дешифрует ключ сессии с помощью своего закрытого ключа и передает его алгоритму программы.

13. Главная микроконтроллерная плата направляет Второй плате сообщение "обмен ключами завершен" через зашифрованную линию связи вниз.

14. Вторая плата отвечает Главной микроконтроллерной плате на сообщение "обмен ключами завершен" через зашифрованную линию связи вверх.

Изобретение предназначено для игровых устройств, таких как игровые автоматы, и, в частности, для методов обеспечения подлинности игрового программного обеспечения. Техническим результатом изобретения является предотвращение несанкционированных изменений, копирования и несанкционированного использования игровой программы. Безопасная смарт-карта или другое безопасное устройство памяти вставляется в порт контроллерной платы, расположенной внутри игровой машины. Смарт-карта программируется на обнаружение зашифрованного "запроса" от процессора хоста CPU и выдачу зашифрованного "ответа". Если процессор хоста определит, что ответ соответствует ожидаемым характеристикам, то CPU удостоверяется в подлинности игровой программы, игра запускается. Обмен запрос-ответ может выполняться перед началом каждой игры на машине или в любое другое время. Если ответ неверен, то CPU хоста выдает команду на остановку игры. Контроль доступа к надлежащим образом запрограммированной смарт-карте позволяет предотвратить исполнение игровой машиной неавторизованные копии игровой программы. 2 н. и 20 з.п. ф-лы, 13 ил.

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

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

обеспечение материнской платы контроллера для игровой машины с процессором и памятью для выполнения игровой программы;

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

выполнение игровой программы для игры на игровой машине, если, по крайней мере, один ключ, хранимый в первом контуре, является надлежащим ключом;

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

память для хранения программы для выполнения игры на игровой машине;

модульный, безопасный первый контур, связанный с основной процессорной системой;

первый контур является безопасным контуром, в котором хранимые данные защищены функциями безопасности;

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

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