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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

В одной из реализаций изобретения к порту внутреннего игрового контроллера игровой машины (или иным образом) подключается безопасная смарт-карта или другое модульное устройство памяти. Плата игрового контроллера содержит центральный процессор (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 ()	Запрос
У=fkpub, (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 ()	Запрос
У=fkpub, (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 на двух платах. Хотя